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
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.
Was spricht denn gegen die Verwendung von strncmp? Ist einfach zu implementieren und tut doch was es soll?
J. F. schrieb: > Was spricht denn gegen die Verwendung von strncmp? das man im bin-file das Passwort im Klartext hat.
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.
>Würde dann wohl schneller laufen als eine Software-MD5
Ist doch vollkommen egal, ob das 10ms oder 100ms dauert
(MEnsch<->Maschine).
Gruß J
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.
Beitrag #5125924 wurde von einem Moderator gelöscht.
Ja OK, klingt logisch! Danke. Also Software MD5 und wenn nötig noch eine Wartezeit nach 3 Fehlversuchen :-D
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.