SSH key login: Vor- und Nachteile?

Jump to last post
Good to know: ssh lässt sich auch mit One Time PassWords verwenden, jedenfalls laut Google ;-).
 
Metal_Warrior schrieb:
Das ist grad nen herber Schock. Von dir hätte ich wirklich mehr Umsicht mit Biometrie erwartet. Grade von dir... :eek:
Zum Vergrößern anklicken....

Mein Handy-Sperrbildschirm verlangt eine nach einem mir bekannten Algorithmus täglich wechselnde 8-stellige PIN mit täglich randomisiertem Zahlenlayout UND den Fingerabdruck, wenn es auf dem Tisch abgelegt oder lange nicht benutzt wurde. Das erkennt das automatisch. Es funktioniert in ⪆99,95% der Fälle (n⪆2000).

Ich erinnere an meine 212-Faktor-Authentifizierung.

BurnerR schrieb:
Good to know: ssh lässt sich auch mit One Time PassWords verwenden, jedenfalls laut Google ;-).
Zum Vergrößern anklicken....

sagte ich doch?

2-Faktor-Authentifizierung, falls mit Passwort eingeloggt wird und beim Key halt nicht.
Zum Vergrößern anklicken....
 
SSH mit Google-Authenticator finde ich sehr praktikabel und ob das wirklich unsicherer ist als per Zertifikat?
Damit kann auch ein fremder PC nichts mit irgendwelchen Login-Daten anfangen.

@Windows - ich nutze dafür
You do not have permission to view link please Anmelden or Registrieren
- geht auch mit key-auth super (und auch mit 2-Faktor)
 
You do not have permission to view link please Anmelden or Registrieren
Warum willst du deine Zugangsdaten einem dritten Dienst anvertrauen, das macht es für dich vielleicht "erst mal" leichter aber es ist definitiv nicht sicherer. Würde ich sagen. Nur weil du dann nicht auf ein Keyfile angewiesen bist, was wäre wenn der Dienst mal ausfällt (warum auch immer?) - kommst du dann auf keine Geräte mehr und hast dich ob du willst oder nicht ausgesperrt. (bzw. so lese ich das.)

Von den SSH Keys kann man immer noch Backups machen, für den Google Service nicht. Du gibst dich dem Unternehmen hin. Im Guten wie im Schlechten. ;)
 
Wer hat von einem dritten Dienst gesprochen?
You do not have permission to view link please Anmelden or Registrieren


Ist zwar von Google aber alles open Source und hat mit Google nur den Namen und die Definition gemein...
Nutze auch nicht das Tool das es von google gebe - das aber auch keine Daten an Google überträgt und offline funktioniert.
 
You do not have permission to view link please Anmelden or Registrieren
Also läuft das nur über den "Client" Server, auf dem Google-Authenthicator installiert ist, und der App?

Der Server, der eine durch Google Authenticator geschützte Anmeldung anbietet, generiert im Rahmen der erstmaligen Initialisierung einen nur 80-Bit-Geheimcode den der Benutzer auf ein persönliches Gerät – in der Regel ein Smartphone – übertragen muss. Hierzu wird das Geheimnis als QR-Code oder als Zeichenkette in Form einer Base32-Darstellung übermittelt.
Zum Vergrößern anklicken....

Aber das danach?

Der Übertragungsvorgang ist, neben dem Umstand, dass der bei der Initialisierung generierte 80-Bit-Geheimcode in Klartext am Gerät gespeichert wird eine Schwäche. Ebenso wird bei Google Authenticator entgegen der Vorgabe im RFC 4226 der Geheimcode in der Länge auf 80 Bit reduziert - nach RFC 4226 soll die Länge des Geheimcodes mindestens 128 Bit aufweisen, eine Länge von 160 Bit ist empfohlen. Da es sich bei dem Geheimnis um das Shared Secret des Verfahrens handelt, darf der Code auch nur von einem vertrauenswürdigen Rechner aus abgelesen werden. Auch eine Fotografie des QR-Codes würde das Geheimnis kompromittieren.
Zum Vergrößern anklicken....
You do not have permission to view link please Anmelden or Registrieren


Bei einem Keybund ist ja nur das Geheimnis im Netz unterwegs? - Den Rest macht der Secret Key um es zu dechiffrieren und der hinterlegte Public Key der "das Geheimnis" generiert bzw. der überprüft wird?

Bin da nicht so tief in der Materie :o

Edit: ssh ist ja verschlüsselt um man-in-the-middle-attacks zu migrieren.

Wobei, https - aber dennoch?
 
Zuletzt bearbeitet:
Der Server also das Ziel auf dem ich mich anmelde und die Software am Handy haben den initial Code und berechnen von da an jede Minute einen neuen 6 stelligen Code.

Zum anmelden benötige ich ein Passwort das man auswendig weiß und den 6 stelligen pin der sich alle 60s ändert.
Da beide Geräte von sich aus die Zahl berechnen bedarf es keiner Übertragung.

Ja der initiale Vorgang ist die Schwäche und man sollte das nicht in einem Online Cafe machen...
Aber der Code wird zumindest in meinem Fall auf der Konsole erzeugt und angezeigt und somit per ssh übertragen. Um ihn hier anzugreifen muss auf meinem Gerät ein schadcode sein der Screenshots macht in diesem Moment.
Und dann scanne ich ihn mit der opensource Software am Handy ab. Backups davon am Handy sind verschlüsselt (alles automatisch ohne extra Konfiguration, einrichten des ganzen geht in 10 min)

Und selbst wenn der initial Code abhanden kommt wird noch das Passwort benötigt...
Also muss sich ein keylogger am initial pc gelaufen sein....
Aber in dem Fall, wenn jemand so viel Kontrolle hat, bringt ein Zertifikat ebenso 0.

Ich denke wenn man viele Server administriert und öfter auf zig Servern sich ein und aus loggt dann ist ein Zertifikat wesentlich praktischer. Wenn man das nur ab und zu benötigt finde ich es so charmanter. Außer jemand kennt einen Punkt der hier wirklich unsicherer ist.
 
You do not have permission to view link please Anmelden or Registrieren
Wobei wir gelernt haben, das Passwörter eine Schwäche sind ;)

Weil sie zu erraten sind, um Menschlich bedienbar zu bleiben. Aber wenn ich richtig verstehe, wird aus dem Password etwas generiert was "stärker" ist, aber halt in Klartext (laut Wikipedia) übermittelt wird?
 
Im Klartext wird die formel übertragen, wobei hier Klartext eben für den Standart gilt und die Anzeige durchaus durch ssl gesichert sein kann wie oben beschrieben.

Der Server denkt sich als symbolisches Beispiel folgendes aus:
Man nehme die aktuelle Uhrzeit in Stunde und Minute, rechne dann abwechseln die erste Zahl mal 3, teilte die nächsten /3 dann mal 3 usw.. Am Ende nimmt man die letzten 6 zahlen. Damit sollte jede Minute eine komplett andere 6 stellige Zahl erzeugt werden.

Das Geheimnis ist nun diese Formel und diese wird einmalig per qr Code übertragen.

Ab da berechnet der Server anhand der Formel jede Minute diese Zahl und die Anwendung am Handy.

Zum Zugang benötigst du aber dann beides... Passwort und den 6 stelligen Code. Und dann bist du natürlich nur User nach dem Login.

Du hast also jede Minute ein neues Passwort das sich aus
2 unbhängigen Quellen zusammen setzt und wenn ein Teil geklaut wird hilft es nichts
 
Okay, verstehe ich, glaube ich... ob es sicherer ist, gute Frage, wenn es über SSH geht, das wäre vermutlich genau so sicher sich an einem Publik Key mit einem Secret Key anzumelden...

Vermutlich wird auch dass Prviat Secret -> Publc nich so einfach gemacht.
 
Google Authenticator ist out, man nutzt heute
You do not have permission to view link please Anmelden or Registrieren
. Da kann man dann auch Backups machen.

EDIT: Der Witz am OTP und warum das sicherer ist als ein Passwort: Wenn ein MITM dazwischen sitzt und das Passwort mitschneidet, kann er sich anmelden. Wenn er das OTP mitschneidet, kann er sich nur in der Zeit anmelden, in der das OTP gültig und noch nicht eingegeben ist – also vermutlich gar nicht. Das "Passwort" (das OTP Secret) verlässt das 2FA-Gerät (=dein Handy) nicht.

Selbes Prinzip wie die TANs beim Online-Banking.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben