Derzeit benutzte Standards sind wohl bcrypt, scrypt und Argon (wegen mir auch noch pbkdf2), daher wäre mein Vorschlag natürlich, einen davon einzusetzen.
Was hat das auf den ersten Blick für Auswirkungen?
1.) Es bräuchte eine ordentliche "Kennwort zurücksetzen"-Funktion, die dem Nutzer per Mail einen einmalig und zeitlich begrenzt gültigen Link zukommen lässt, unter dem er sein neues Kennwort eingeben kann.
2.) Die SID als Parameter ist ja im wesentlichen schon ein (wenn auch nach heutigen Maßstäben eher schwacher) Hash, der zudem auch nur die ersten 8 Zeichen des Kennworts verwertet. Ob diese im gleichen Zug abgeschafft würde ist natürlich die Frage, da zumindest die wkAPI diese noch verwenden könnte (je nachdem, welche Funktionen man nutzt). Das dürfte also zumindest für einige kaputte Dinge sorgen. Man könnte zwar in die URLs bzw. Parameter stattdessen das Klartext-Kennwort nehmen (wie auch in der API, die der wkAPI die Daten bereitstellt), das hat aber die Unschönheit, dass das Kennwort in euren Access-Logs auftauchen könnte, was ich auch eher als ungünstig bezeichnen würde. Evtl. kann für sowas ein separates API-Token vorgesehen werden? Lohnt sich der Aufwand hierfür im Hinblick auf die Größe der Entwicklergemeinde? Wahrscheinlich eher nicht
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
Ich habe auf Anhieb nicht herausfinden können, ob die DSGVO auch für dieses Thema eine Regelung hat, aber Stand der Technik ist die jetzige Vorgehensweise sowieso schon seit Jahren nicht mehr, insofern erschien mir der Zeitpunkt passend, das nochmal anzusprechen. Wie ihr das priorisiert müsst ihr letztlich selbst entscheiden
![Smilie :)](./images/smilies/icon_smile.gif)