Passworts auf dem Server oder auf dem Endgerät hashen?

[Funkener]

Hallo zusammen,

ist es datenschutzrechtlich bedenklich die Passworts der Nutzer entgegen zu nehmen und dann erst an den Server zu senden, um diese dann dort zu hashen? Ich speichere die Passwörter ja nicht ab, sondern verarbeite diese nur zu einem Hash, welcher dann abgelegt wird.

Oder macht man das üblicherweise vorher auf dem Endgerät? Ich frage das explizit nochmal, weil wir in Deutschland ja sehr speziell mit Datenschutz sind. Wie macht ihr das?

Vielen Dank & Gruß!

 

[till69]

und dann erst an den Server zu senden, um diese dann dort zu hashen?

Keine gute Idee

Und noch besser:
https://de.wikipedia.org/wiki/Salt_(Kryptologie)

 

[netzgestaltung]

Die meisten verlassen sich auf eine library oder ein system, dass das zuverlässig erledigt und updates erhält.

Grundsätzlich mußt du dich zunächst um die verschlüsselte übertragung kümmern (https) und sicherstellen das kein schadcode ankommt. dann kannst du am server hashen(und salten nicht vergessen) und speichern.

je nach architektur wird das aber schon erst am server gemacht.

Edit: Beispiel WordPress/PHP source code:
wp_set_password: https://developer.wordpress.org/reference/functions/wp_set_password/
wp_hash_password: https://developer.wordpress.org/reference/functions/wp_hash_password/

WordPress verlässt sich hier auf die Library phpass - das würde ich beispielsweise auch anraten. Scheint nicht mehr nötig wenn es nur neue PHP (5.5+) Versionen gibt mit denen gehasht wird.

auch die wp_hash funktion ist interessant: https://developer.wordpress.org/reference/functions/wp_hash/

 

[KitKat::new()]

Keine gute Idee

warum?

 

[till69]

Weil das Passwort das Endgerät im Klartext verlässt

 

[KitKat::new()]

Oder macht man das üblicherweise vorher auf dem Endgerät?

Wenn du es auf dem Client machst, musst du es auf dem Server trotzdem nochmal machen, weil durchs Hashen auf dem Client der Hash des Passworts das eigentliche Passwort wird, und damit das Passwort ungehashed in der DB landen würde.

Damit der Serveradmin nicht an das eigentliche PW kommt, würde ich sowohl auf dem Server als auch am Client hashen.

Weil das Passwort das Endgerät im Klartext verlässt

ich gehe mal von HTTPS aus...

 

[netzgestaltung]

Wobei der Serveradmin immer funktionen manipulieren kann wenn er nur möchte. daher ist das kaum sicherheit extra.

 

[KitKat::new()]

Der Code auf dem Endgerät kann ggf. verifiziert (z.B. Code Audit) und dadurch gegen Manipulationen geschützt werden.

 

[RalphS]

Die Frage ist, was erreicht werden soll.

Klar ist: wenn Benutzerdaten wie Paßwörter über die Leitung gehen sollen, müssen sie verschlüsselt sein.

Die Frage die sich stellt, ist also: wenn ich einen verschlüsselten Datenstrom über HTTPS hab, darf ich mich dann auf dessen Integrität und Vertraulichkeit verlassen, oder darf ich das nicht und muß ich zusätzlich etwas tun?

Sicherheitstechnisch "optimal" wäre es wohl, wenn man die Aufgabe zerlegt und anteilig auf dem Client und dem Server erstellen läßt, und ich denke immer noch, daß ein Hashing mit zwei verschiedenen Algorithmen ebenfalls helfen könnte.

Natürlich stellt sich die Frage dann auch, wie sinnvoll das ist. Es dauert ja auch extra.

Otto Normalanwendung macht einfach einen auf POST <form>, entweder Klartext oder (hurra) base64 über HTTPS.
Man selber kann das sicher im Einzelfall anders handhaben -- und sich von allen anderen zu unterscheiden ist im Hinblick auf Sicherheit meistens vorteilhaft --- aber am Ende des Tages ist zumindest meines Erachtens die TLS-Verbindung mit aktueller Parametrisierung ausreichend.

 

[BeBur]

Oder macht man das üblicherweise vorher auf dem Endgerät?

Zum rechtlichen Aspekt kann ich dir nicht viel sagen, aber die Norm afaik ist, dass das Passwort auf dem Server in Klartext ankommt, den Grund haben KitKat und netzgestaltung genannt.

Datenschutzrechtlich würde ich vermuten ist das Passwort eher unproblematisch, da es kein personenbezogenes Datum ist.

 

[andy_m4]

Datenschutzrechtlich würde ich vermuten ist das Passwort eher unproblematisch, da es kein personenbezogenes Datum ist.

Ob personenbezogene Daten personenbezogene Daten sind hängt davon ab, ob ein Bezug zu einer Person hergestellt werden kann. Ein Datum ansich ist selten personenbezogen. Selbst Dein Geburtsdatum ist das nicht. Schon allein deshalb, weil an dem Tag mehr Menschen als Du geboren sein werden. :-)

Wesentlich für den Personenbezug ist also, ob das Datum einer Person zugeordnet werden kann. Das kann z.B. deshalb sein, weil das Passwort zusammen mit anderen Daten (z.B. bei einer Anmeldung) übertragen wird oder aber auch weil man mit Hilfe des Passwortes an weitere Informationen kommt (also beispielsweise damit auf dem Server einloggen und da vollständige Profildaten einsehen).

 

[Funkener]

Vielen Dank an alle für jeglichen Input!

Hintergrund meiner Frage ist, dass ein Programmierer für mich arbeitet und einen massiven Fehler begangen hat, weshalb ich mich nun selber einlesen muss. Ich hatte mich gewundert, warum alle Passwörter in der Datenbank mit den selben Zeichen anfangen. Ich fragte ihn, welchen Hash Algorythmus er nutzt. Dann zeigte er mir den Code, welchen ich auch ohne zu Prohrammieren verstanden habe. Er hat einfach die Passwörter mit AES verschlüsselt, dessen Key dann im Quellcode liegt. Daher wollte ich mich nun schlau machen, wie die ganze Nutzergeschichte eigentlich gehandhabt wird. Angetan hat es mir dann JWT und Argon2 für die Passwörter. Allerdings....

Die meisten verlassen sich auf eine library oder ein system, dass das zuverlässig erledigt und updates erhält.

.. tendiere ich dann nun doch zu einem Anbieter, welcher das komplett für mich übernimmt. Denn das Vertrauen in dem Programmierer habe ich etwas verloren und ich möchte nicht schlampig mit den Nutzerdaten umgehen. Daher habe ich mich wohl nun für "Cognito" von AWS entschieden. Auth0 ist mir zu teuer und von Firebase nutzen wir bisher glaube noch nichts. AWS Services allerdings schon, weshalb sich dann eben ein weiterer Service von AWS anbieten würde.

Bin zwar kein Freund von AWS und Co., doch mein Budget ist eben begrenzt, wodurch ich leider nicht selber alles sicher programmieren lassen kann. Und AWS lockt halt auch extrem mit kostenlosen Kontigenten.

Falls mir jemand noch Tipps auf den Weg geben kann, vielleicht auch bzgl. AWS Cognito, so würde ich mich sehr darüber freuen! Schönen Tag euch noch!

 

[BeBur]

Denn das Vertrauen in dem Programmierer habe ich etwas verloren und ich möchte nicht schlampig mit den Nutzerdaten umgehen.

Ja zu recht, den kannst du guten Gewissens 'feuern', den würde ich gar nicht mehr einsetzen für irgendwas, sondern wen anders suchen.

Falls mir jemand noch Tipps auf den Weg geben kann, vielleicht auch bzgl. AWS Cognito

Was für einen Tech-Stack habt ihr denn, also welche Programmiersprache/Framework? AWS Cognito ist mMn overkill für dich, es gibt etablierte Prozesse für solche Logins an denen dein Programmierer schlicht dran vorbei gearbeitet hat.

 

[Funkener]

Ich zahle halt auch nicht viel, weshalb es schon in Ordnung ist, dass er nicht alles weiß und wir zusammen lernen. Programmieren kann er echt gut, doch in seinem Land gibt es halt keinen Datenschutz, weshalb er noch nicht viel mit Verschlüsselung am Hut hatte. Ist für mich in Ordnung, dass ich dann eben auch Input bringen muss.

Was für einen Tech-Stack habt ihr denn, also welche Programmiersprache/Framework?

Wir nutzen React Native, es ist eine App für iOS und Android. Wir erwarten viele Nutzer und er kennt sich auch bereits mit AWS aus, weshalb wir damit arbeiten wollen. Selbst wenn es overkill ist, bekomme ich das alles für 1 Jahr kostenlos. Und das ist mMn. eben ein großer Vorteil.

 

[BeBur]

Ich zahle halt auch nicht viel, weshalb es schon in Ordnung ist, dass er nicht alles weiß und wir zusammen lernen. Programmieren kann er echt gut, doch in seinem Land gibt es halt keinen Datenschutz

Ich will dir das gar nicht ausreden, aber es sollte schon noch angemerkt werden, dass Hashing von Passwörtern international der absolute Standard ist, niemand der professionell Web-Entwicklung betrieben hat käme auf die Idee, Passwörter auf dem Server zu verschlüsseln und wenn man entsprechend im Internet sucht "<server stack> + how to store passwords" dann findet man eigentlich auch nur Anleitung die dazu führen, dass ein Hashing stattfindet.
Das hat nichts mit Datenschutz zu tun, sondern ist etablierter Teil des Handwerks.

 

[Ranayna]

Wenn man auf dem Client hasht, dann ist der Hash quasi das Passwort.
Mopst dir jemand den Hash aus der Datenbank, wie auch immer das passiert, hat er damit Zugang zum Account.
Also muesstest du auf dem Server vor dem Abspeichern des Passwortes nochmal hashen. Oder gleich nur auf dem Server hashen.
Das setzt Trasportsicherheit (HTTPS) vorraus, aber die ist ja heutzutage absoluter Standard.

 

[owned139]

Weil das Passwort das Endgerät im Klartext verlässt

HTTPS?

Das setzt Trasportsicherheit (HTTPS) vorraus, aber die ist ja heutzutage absoluter Standard.

Sowohl Wordpress, als auch TYPO3 hashen das Passwort nur Serverseitig und das sollte mit HTTPS auch kein Problem darstellen oder sehe ich das falsch?

 

[Ranayna]

Richtig, das Passwort muss auf dem Server gehasht werden.

Es geht dabei ja um folgendes: Man hasht ja, damit jemand, der an die Datenbank herankommt, nicht an die eigendlichen Passwoerter der User kommt.
Wenn du jetzt aber auf dem Client hashst, und auf dem Server nicht nochmal, wird der Hash im Endeffekt zum Passwort. Denn wie du den Hash berechnest ist nicht geheim, da der Code auf dem Client laeuft, und niemand hindert den Hacker daran, die Hashberechnung im Code einfach zu ueberspringen und direkt den gestohlenen Hash zu uebermitteln.

Dann ist er direkt drin.
Es gibt dann hoechstens den kleinen Trost das der Hacker trotzdem nicht das eigendliche Passwort hat um es auf anderen Webseiten auszuprobieren.

Wenn wir jetzt Transportsicherheit vorraussetzen, gibt es keinen Grund das Passwort auf dem Client "vorzuhashen". Wenn der potenzielle Angreifer schon auf dem Client ist um das Passwort da abzugreifen, auf welche Art und Weise auch immer, dann ist eh alles an Massnahmen hinfaellig.

Sicherheitsrelevanter Code hat auf dem Client eigendlich nichts verloren. Ein Client der nicht unter deiner Kontrolle ist, muss pauschal als Unsicher betrachtet werden, denn es ist trivial lokal auf dem Client ausgefuehres Javascript oder anderen Code zu modifizieren.

 

[AW4]

Denn wie du den Hash berechnest ist nicht geheim, da der Code auf dem Client laeuft[...]

Es ist alles richtig was du schreibst, nur hier hast du einen kleinen Verdreher drin.
Die Art und Weise, wie die Schlüsselableitung erfolgt, um vom Passwort in Klartext auf den Schlüssel in der Datenbank zu kommen, darf sehr wohl öffentlich und jedem bekannt sein.
Es muss lediglich sichergestellt sein, dass die gewählte Methode für die Schlüsselableitung auch tatsächlich kryptografisch sicher, aufwändig genug und korrekt implementiert ist.
Das einzig geheime in diesem Prozess muss, bzw. darf das Klartextpasswort sein.

Wenn man auf dem Client hasht, dann ist der Hash quasi das Passwort.
Mopst dir jemand den Hash aus der Datenbank, wie auch immer das passiert, hat er damit Zugang zum Account.

Hier nennst du schon den einzigen Grund dafür, dass der Server den Zugangsschlüssel aus dem Klartextpasswort selber ableiten MUSS und nicht einfach einen übersendeten, schon abgeleiteten Schlüssel hernehmen darf.

 

[KitKat::new()]

Wenn wir jetzt Transportsicherheit vorraussetzen, gibt es keinen Grund das Passwort auf dem Client "vorzuhashen".

Doch, gibt es:

Damit der Serveradmin nicht an das eigentliche PW kommt

Verhindert z.B., dass der Serverbetreiber oder Angreifer desselben das Passwort abgreifen können und z.B. für andere Dienste missbrauchen können, wo man ggf. ein ähnliches Passwort genutzt hat.
Nicht zuletzt will man vielleicht auch nicht, dass andere mein ausgedachten PW lesen können.

Sicherheitsrelevanter Code hat auf dem Client eigendlich nichts verloren.

Vielleicht noch Mal nachdenken bevor man Verallgemeinerungen absendet.
HTTPS, kein sicherheitsrelevanter Code auf dem Client?
MEGOLM um Ende-zu-Ende Verschlüsselung zu realisieren auch nicht?
oder ist beides nicht sinnvoll?