Hallo,
ich habe in meinem µC Code eine Debug Schnittstelle übers
Terminal/Console. Mit einem Parser kann ich verschiedene Debug Ebenen
öffnen. Diese sind Rollenbezogen, d.h. "User", "Wartungspersonal",
"Superuser", "Entwickler".
Die Ebenen sollen mittels Passwort geschützt werden. Insbesondere der
Bereich "Entwickler" hat keinen zu interessieren, da ich hier auch den
kompletten Flash löschen kann.
Gibt es einen guten Codeabschnitt für die Passwortabfrage oder macht Ihr
das klassisch über strncmp?
Ich hatte schon das Projekt:
https://github.com/cocagne/csrp als Ideengeber, aber die Jungs arbeiten
mit OpenSSL. Ist vielleicht doch ein wenig übertrieben.
Bin für Ideen offen.
Gruß,
Freddy
Wenn du FW als bin verändert wüde ich das Passwort bitweise über die
Wortlänge vor dem Strcmp rotieren das sollte gegen unlegitimiertes
hacken genügen
namaste
Markus M. schrieb:> Ich würde einen Hash des Passwortes speichern und gegen diesen testen.> CRC-16 sollte ja schon ausreichen. MD5 o.ä. wäre wohl etwas übertrieben.
Hashen ist gut, aber Passworte mit CRC "hashen" ist Unsinn. MD5 ist auch
auf kleinen Controllern gut machbar.
Und mindestens den Usernamen als salt sollte auch sein.
Peter II schrieb:> das man im bin-file das Passwort im Klartext hat.
Ja das stimmt schon, aber dann müsste man erstmal darauf kommen, dass
"dieser" Klartext dem Passwort entspricht (OK, Sicherheit ist was
anderes)
Aber, wenn man das PW im Flash oder anderem Speicher (SD) ablegt, weil
es vllt. für jeden USER angepasst werden kann, dann würde strncmp doch
auch gehen, oder nicht?
Adam P. schrieb:> Aber, wenn man das PW im Flash oder anderem Speicher (SD) ablegt, weil> es vllt. für jeden USER angepasst werden kann, dann würde strncmp doch> auch gehen, oder nicht?
klar würde es gehen.
Adam P. schrieb:> Aber, wenn man das PW im Flash oder anderem Speicher (SD) ablegt, weil> es vllt. für jeden USER angepasst werden kann, dann würde strncmp doch> auch gehen, oder nicht?
Natürlich geht es. Warum auch nicht. Nur sollte man einfach Passwörter
nicht im Klartext irgendwohin legen. Du musst auch so sehen dass diese
Passwörter vielleicht noch woanders genutzt werden. Es ist nicht ok,
einen Nutzer ein Passwort eingeben zu lassen und es dann auslesbar zu
speichern.
Speicher einen HA1 = MD5(realm:username:passwort) ab. Als Realm nimmst
du einen festen String der deine Anwendung oder dein Gerät beschreibt.
Alles klar, super!
edit:
Also könnte man beim Atmel SAM4 auch die interne AES nutzen?
Würde dann wohl schneller laufen als eine Software-MD5, wahrscheinlich.
Adam P. schrieb:> Also könnte man beim Atmel SAM4 auch die interne AES nutzen?> Würde dann wohl schneller laufen als eine Software-MD5, wahrscheinlich.
das ist aber sehr schlecht wenn es schneller läuft. Dann kann man das
System besser hacken. Für Passwörter will man verfahren die langsam
sind.
z.b. https://de.wikipedia.org/wiki/PBKDF2
Adam P. schrieb:> Alles klar, super!>> edit:> Also könnte man beim Atmel SAM4 auch die interne AES nutzen?> Würde dann wohl schneller laufen als eine Software-MD5, wahrscheinlich.
Man kann. Hat aber nicht die gleiche Wirkung. AES benötigt einen
Schlüssel und ist der Schlüssel bekannt kann man das Passwort wieder
entschlüsseln.
Und wo und wie willst du den Schlüssel ablegen? Merkst du was? Du drehst
dich dann im Kreis.
Man nimmt Hashes weil man genau diese Umkehrung unmöglich machen will.
>das ist aber sehr schlecht wenn es schneller läuft. Dann kann man das>System besser hacken.
Man kann natürlich auch einfach die Ausgabe verzögern, so entlastet man
die CPU. Also die AES-Einheit nutzen aber die Ausgabe um ne halbe
Sekunde vezögern...
Gruß
Peter II schrieb:> Adam P. schrieb:>> Also könnte man beim Atmel SAM4 auch die interne AES nutzen?>> Würde dann wohl schneller laufen als eine Software-MD5, wahrscheinlich.>> das ist aber sehr schlecht wenn es schneller läuft. Dann kann man das> System besser hacken. Für Passwörter will man verfahren die langsam> sind.>> z.b. https://de.wikipedia.org/wiki/PBKDF2
Genau so würde ich es auch machen. Die Anzahl der Iterationen natürlich
nur so hoch wählen, dass die Wartezeit noch erträglich ist.
Adam P. schrieb:> Ja OK, klingt logisch! Danke.>> Also Software MD5 und wenn nötig noch eine Wartezeit nach 3> Fehlversuchen :-D
Ja, aber du musst unterscheiden.
Will jemand das Passwort über die Console erraten, kannst du das mit
einer Wartezeit im Programm usw. sehr gut abfangen.
Die vorgeschlagenen langsamen Algos kommen dann zum tragen wenn deine
ganze Datenbank abhanden gekommen ist, und die Hashes dem Angreifer
vorliegen und er eine Brute-Force Attacke darauf machen will.
Ich würde aber auch sagen, dass ich dem zeitlichen Aspekt hier nicht
viel Beachtung schenken würde. Gesalzene MD5 Hashes wie HA1, bieten hier
mehr als genug Widerstand.
Nachtrag:
J. F. schrieb:> Was spricht denn gegen die Verwendung von strncmp?
damit hätte man sogar ein Sicherheitsproblem. Bei strncmp wird beim
ersten unterschied abgebrochen. Die Funktion ist also langsamer je mehr
Zeichen vom Passwort stimmen. Das könnte man ausnutzen im das Passwort
zu knacken. Selbst ein einfachen sleep dahinter würde nicht reiche, man
müsste ein sleep mit Random Zeit einabauen.
Danke für die vielen Ideen und Anregungen
Ich habe jetzt mein Passwort SHA1 kodiert und die Passwortabfrage
dementsprechend angepasst.
Sicherlich gilt SHA1 momentan als knackbar, aber bei der von mir
angedachten Anwendung ist dies erstmal ausreichend. Bei Gelegenheit
werde ich mich nochmal damit auseinandersetzen wieviel Aufwand ein
SHA256 wäre.
Viele Grüße
Freddy schrieb:> Sicherlich gilt SHA1 momentan als knackbar
Absolut ausreichend würde ich auch sagen. "Knackbar" ist bei Hash
Algorithmen auch differenziert zu sehen.
In deinem Fall willst du nur verhindern dass jemand das Klartextpasswort
bekommt, dafür bleibt immer nur Brute-Force und das ist immer Mist für
den Angreifer.
MD5 gilt z.B. schon länger als "broken", aber nur was die
Kollisionsresistenz angeht. D.h. signieren sollte man damit nicht mehr
(tut man auch schon lange nicht mehr), aber für deinen Zweck immer noch
sicher (abgesehen von den NUR 128 Bit Länge).
Ähnliches gilt auch für SHA1.
