REDWEB.APP
Du musst kein Blockchain-, Bitcoin- oder IT-Experte sein, um zu verstehen, wie deine Wallet geschützt wird.
Auf dieser Seite erklären wir in einfacher Sprache, was mit deinen 12 oder 24 Sicherheitswörtern passiert, was RedDrive speichert, was Redweb sehen kann – und was selbst ein Angreifer mit gestohlenen Serverdaten noch benötigen würde, um deine Wallet zu übernehmen.
Eine Krypto-Wallet ist nicht wirklich eine digitale Geldbörse, in der deine Coins wie Geldscheine herumliegen.
Deine Bitcoin, Solana oder andere Blockchain-Werte befinden sich auf der jeweiligen Blockchain.
Deine Wallet besitzt stattdessen die geheimen Schlüssel, mit denen du beweisen kannst:
Wer diese geheimen Schlüssel kontrolliert, kontrolliert die Wallet. Deshalb ist der Schutz dieser Schlüssel der wichtigste Teil einer Wallet.
Beim Erstellen oder Wiederherstellen einer Wallet begegnen dir häufig 12 oder 24 Wörter.
Diese Wörter nennt man unter anderem:
Sie sind extrem wichtig.
Deshalb solltest du diese Wörter niemals per E-Mail verschicken, niemals in einem Chat senden und niemals einer Person mitteilen, die behauptet, sie für Support, Wartung oder eine Auszahlung zu benötigen.
Ein seriöser Redweb-Support muss deine vollständige Seed Phrase niemals von dir verlangen.
Bei der Redweb Wallet werden neue Recovery-Wörter direkt im Browser auf deinem Gerät erzeugt.
Dafür wird eine kryptographisch sichere Zufallsquelle des Browsers verwendet.
Das ist wichtig, denn sichere Wallet-Wörter dürfen nicht aus leicht vorhersehbaren Informationen wie deinem Namen, deiner E-Mail-Adresse, einer User-ID oder der aktuellen Uhrzeit berechnet werden.
Nach dem durchgeführten Security-Audit: Nein.
Im geprüften Datenfluss werden die Recovery-Wörter nicht als Klartext an den Redweb-Server übertragen.
Sie werden auch nicht einfach in einer normalen Datenbankspalte gespeichert.
Das bedeutet:
„Custodial“ bedeutet vereinfacht:
Das ist beispielsweise bei vielen zentralen Kryptobörsen der Fall. Du besitzt dort ein Benutzerkonto, aber die Plattform kontrolliert technisch die eigentlichen Wallet-Schlüssel.
„Non-Custodial“ bedeutet dagegen:
Bei der Redweb Wallet werden die Wallet-Schlüssel lokal erzeugt und verwendet. Die Wallet wurde so aufgebaut, dass gespeicherte Redweb-Serverdaten allein nicht ausreichen sollen, um deine Wallet zu rekonstruieren.
Das ist einer der wichtigsten Punkte der gesamten Sicherheitsarchitektur.
Man könnte denken:
Nein – nicht als normal lesbarer Klartext.
Bevor das Wallet-Backup zu RedDrive geschickt wird, wird der sicherheitskritische Inhalt bereits auf deinem Gerät verschlüsselt.
Man kann sich das wie einen Tresor vorstellen.
RedDrive bekommt nicht den geöffneten Tresor samt Inhalt, sondern einen bereits verschlossenen Tresor.
Zusätzlich schützt Redweb diesen verschlüsselten Datensatz auf der Serverseite noch mit einer weiteren Verschlüsselungsschicht.
Hier muss man zwischen zwei Verschlüsselungsschichten unterscheiden.
Diese Schicht schützt die gespeicherte Datei innerhalb der Redweb-Infrastruktur.
Redweb besitzt technisch den Schlüssel für diese äußere Schicht.
Innerhalb dieser äußeren Datei befindet sich aber weiterhin der bereits auf deinem Gerät verschlüsselte Wallet-Tresor.
Für dessen Entschlüsselung benötigt man dein eigenes Wallet-Geheimnis, zum Beispiel dein Wallet-Passwort oder die entsprechende Passkey-Freigabe.
Deshalb reicht der Redweb-Server-Schlüssel allein nicht aus, um unmittelbar deine Recovery Phrase zu erhalten.
Nehmen wir ein extremes Beispiel:
Das bedeutet nach dem geprüften System noch nicht automatisch, dass der Angreifer deine Wallet besitzt.
Er erhält zunächst verschlüsselte Daten.
Die Recovery Phrase befindet sich darin nicht offen lesbar.
Auch ein Datenbank-Leak allein reicht nach der geprüften Architektur nicht aus, um die Wallet wiederherzustellen.
Die Datenbank enthält unter anderem Zuordnungen und technische Metadaten – aber nicht einfach deine Mnemonic oder deinen Private Key.
Das Security-Audit hat ausdrücklich auch dieses Szenario untersucht.
Nehmen wir an, ein Angreifer besitzt:
Damit kann ein Angreifer die äußere Redweb-Schicht öffnen.
Er landet aber anschließend wieder vor dem verschlüsselten Wallet-Tresor.
Vereinfacht sieht es folgendermaßen aus:
| Was wurde gestohlen? | Wallet direkt übernehmbar? |
|---|---|
| Nur Redweb-Datenbank | Nein |
| Nur RedDrive-Daten | Nein |
| Datenbank + RedDrive | Nein |
| Datenbank + RedDrive + Server-Schlüssel | Nicht unmittelbar. Der innere Wallet-Schutz bleibt bestehen. |
| Verschlüsseltes Wallet-Backup + richtiges Wallet-Passwort | Ja |
| Die vollständige 12/24-Wörter-Recovery-Phrase | Ja |
| Eine bereits entsperrte und vollständig kontrollierte Browser-Sitzung | Transaktionen können unter Umständen ausgeführt werden. |
Ein verschlüsselter Tresor ist nur so sicher wie der Schlüssel, mit dem er geschützt wird.
Die Redweb Wallet verwendet derzeit eine starke, absichtlich rechenaufwendige Passwortableitung mit vielen Berechnungsschritten, bevor daraus der eigentliche Verschlüsselungsschlüssel entsteht.
Das erschwert das automatische Ausprobieren von Passwörtern erheblich.
Trotzdem gilt:
Beispiel:
Ein Passwort wie „passwort1234“ ist trotz ausreichender Zeichenlänge keine gute Idee.
Besser ist eine lange, einzigartige Passphrase, die du nirgendwo sonst benutzt.
Nein.
Das normale Passwort für deinen Redweb-Account und das Verschlüsselungsgeheimnis deiner Wallet sind technisch voneinander getrennt.
Das ist wichtig.
Wenn jemand dein normales Redweb-Login übernimmt, erhält er dadurch nicht automatisch dein Wallet-Passwort.
Auch ein Zurücksetzen deines normalen Redweb-Passworts entschlüsselt nicht automatisch deine Wallet.
Die Redweb Wallet unterstützt zusätzlich einen Passkey-basierten Schutzmechanismus.
Dabei wird das benötigte Geheimnis nicht einfach als normales Passwort gespeichert.
Stattdessen wird eine vom authentifizierten Passkey bereitgestellte kryptographische Funktion verwendet, um den Wallet-Schlüssel lokal herzuleiten.
Für Einsteiger kann man es sich ungefähr so vorstellen:
Wenn du Kryptowährungen verschickst, muss deine Transaktion kryptographisch unterschrieben werden.
Diese Signatur beweist der Blockchain:
In der geprüften Redweb-Wallet geschieht diese Signierung lokal in der Wallet-Anwendung.
Der Private Key wird dafür nicht an den Redweb-Server geschickt.
Die Private Keys werden nicht einfach dauerhaft im Klartext in Browser-Speichern wie localStorage abgelegt.
Dauerhaft gespeichert wird der verschlüsselte Wallet-Tresor.
Wenn du deine Wallet entsperrst, muss dein Browser natürlich kurzfristig mit dem entschlüsselten Schlüsselmaterial arbeiten können.
Sonst könnte er keine Transaktionen für dich signieren.
Nein.
Das gilt nicht nur für Redweb.
Keine Software-Wallet, Hardware-Wallet, Bank, Kryptobörse oder IT-Plattform kann seriös behaupten, unter allen denkbaren Umständen zu 100 % unhackbar zu sein.
Gute Sicherheit bedeutet deshalb:
Hier kommt ein Punkt, den wir bewusst nicht verschweigen wollen.
Die Redweb Wallet läuft als Webanwendung.
Das bedeutet: Dein Browser lädt Programmcode von wallet.redweb.app und führt diesen Code auf deinem Gerät aus.
Solange dieser Code unverändert und vertrauenswürdig ist, funktionieren die beschriebenen Sicherheitsmechanismen.
Würde jedoch ein Angreifer vollständige Kontrolle über die Auslieferung der Wallet-Anwendung erhalten und könnte er den Programmcode verändern, könnte er theoretisch versuchen, zukünftige Eingaben abzufangen.
Beispielsweise dann, wenn ein Benutzer danach:
Man muss zwei völlig unterschiedliche Situationen unterscheiden.
Der Hacker stiehlt beispielsweise:
In diesem Szenario bleibt der innere Wallet-Tresor nach der geprüften Architektur weiterhin durch dein Benutzergeheimnis geschützt.
Wenn ein Hacker dauerhaft kontrolliert, welchen JavaScript-Code dein Browser von wallet.redweb.app erhält, könnte er versuchen, das Geheimnis beim nächsten Entsperren abzufangen.
Diese beiden Szenarien darf man nicht miteinander verwechseln.
Für die Wallet wurde eine umfassende technische Prüfung des vorhandenen Codes und der Sicherheitsarchitektur durchgeführt.
Dabei wurden unter anderem untersucht:
| Bereich | Audit-Ergebnis |
|---|---|
| Erzeugung neuer Recovery-Wörter | PASS |
| Private Keys verlassen das Gerät nicht | PASS |
| RedDrive-Backup | PASS |
| Clientseitige Verschlüsselung | PASS |
| Lokale Transaktionssignierung | PASS |
| Wallet-Passwortschutz | PARTIAL |
| Schutz gegen kompromittierten Wallet-Webcode | PARTIAL |
| Gesamte Non-Custodial-Bewertung | PARTIAL |
„PARTIAL“ bedeutet hier nicht, dass deine Wallet-Schlüssel auf dem Server liegen.
Die Bewertung berücksichtigt insbesondere die grundsätzliche Vertrauensgrenze einer browserbasierten Wallet: Wer irgendwann den ausgelieferten Wallet-Code kontrolliert, könnte zukünftige Wallet-Vorgänge angreifen.
Im untersuchten Stand wurde kein aktueller kritischer Fund nachgewiesen, bei dem allein die heute serverseitig gespeicherten Daten unmittelbar die Recovery Phrase oder einen Private Key preisgeben.
Das bedeutet jedoch nicht, dass es nichts mehr zu verbessern gibt.
Sicherheit ist ein fortlaufender Prozess.
Aus dem Audit wurde ein eigener Security-Hardening-Plan erstellt.
Dazu gehören unter anderem:
Selbst die beste Verschlüsselung kann nicht verhindern, dass ein Benutzer seine eigenen Geheimnisse freiwillig weitergibt.
Deshalb solltest du einige einfache Regeln beachten:
Nach dem geprüften Wallet-Datenfluss werden die Wörter nicht als Klartext an den Redweb-Server übertragen.
Nein. Im geprüften System werden Private Keys nicht dauerhaft als Klartext in der Redweb-Datenbank gespeichert.
Nein. RedDrive erhält einen bereits clientseitig verschlüsselten Wallet-Tresor.
Dein normales Redweb-Passwort und dein Wallet-Geheimnis sind voneinander getrennt. Ein normales Account-Passwort-Reset entschlüsselt nicht automatisch deine Wallet.
Dadurch besitzt die Person nicht automatisch deine Wallet. Ein kompromittierter Redweb-Account ist trotzdem ernst zu nehmen, weil der Angreifer beispielsweise Zugriff auf verschlüsselte Backup-Daten und Account-Funktionen erhalten könnte.
Das Wallet-Passwort allein reicht ohne den zugehörigen verschlüsselten Wallet-Tresor nicht aus.
Hat ein Angreifer jedoch sowohl dein Wallet-Backup als auch das richtige Wallet-Passwort, kann die Wallet rekonstruiert werden.
Dann musst du davon ausgehen, dass deine Wallet kompromittiert ist.
Die Recovery Phrase ist der wichtigste Wiederherstellungsschlüssel deiner Wallet.
Über die regulären gespeicherten Serverdaten und normalen Verwaltungsfunktionen reicht ein Administratorzugriff nach dem Audit nicht aus, um die Recovery Phrase zu rekonstruieren.
Die Sicherheitsarchitektur ist gerade darauf ausgelegt, dass Redweb nicht einfach eine Klartextkopie deiner Recovery Phrase besitzt.
Das erhöht deine Selbstbestimmung – bedeutet aber auch, dass du selbst Verantwortung für deine Recovery-Möglichkeiten trägst.
Nein.
RedDrive speichert einen verschlüsselten Wallet-Tresor und nicht einfach ein Textdokument mit deinen 12 oder 24 Wörtern.
Nein. Eine seriöse Sicherheitsbeschreibung sollte niemals behaupten, eine Software sei absolut unhackbar.
Die Redweb Wallet verwendet mehrere Schutzschichten und wurde gezielt auf verschiedene Angriffsszenarien geprüft. Trotzdem existieren – wie bei jeder Software-Wallet – Restrisiken.
Die wichtigste Erkenntnis des Security-Audits ist:
Neue Recovery-Wörter werden lokal erzeugt.
Private Keys bleiben im geprüften Datenfluss auf dem Gerät.
Transaktionen werden lokal signiert.
RedDrive erhält einen bereits verschlüsselten Wallet-Tresor.
Selbst ein vollständiger passiver Abzug von Datenbank, RedDrive und Server-Konfiguration reicht ohne ein zusätzliches Benutzergeheimnis nicht unmittelbar aus, um deine Recovery Phrase zu rekonstruieren.
Gleichzeitig ist Redweb eine browserbasierte Software-Wallet. Deshalb bleiben Browser-, Geräte-, Passwort- und Software-Auslieferungsrisiken relevant.
Die Sicherheit deiner Wallet besteht daher aus zwei Teilen:
Beides zusammen entscheidet über die tatsächliche Sicherheit deiner Wallet.
Unsere Zielsetzung ist einfach:
Selbst wenn jemand gespeicherte Redweb-, Datenbank- und RedDrive-Daten kopiert, soll daraus ohne dein eigenes Benutzergeheimnis keine vollständige Wallet entstehen.
Dieses Prinzip wird bei zukünftigen Änderungen an der Wallet als zentrale Sicherheitsanforderung weitergeführt.