Hi Mike, that is a very good suggestion. Just make sure this fits into the architecture well. I'd check the string as it gets stored, not just the used algorithm. With bcrypt, for example, the cost parameter could change in future, so an update in the DB would also be needed. Please also provide unit tests for this. Thanks a lot in advance! Regards, mg Am 08.01.14 08:16, schrieb Michiel Beijen:
Hi all ;-)
I am really happy with the bcrypt password hashing mechanism that Martin and me added to OTRS 3.3.
That said, one thing that is not so nice is that passwords which already exists are not upgraded.
Of course, for upgrading we would need the plain password. So what we could do is, when a user logs in, compare the encryption mechanism of the password hash with the configured password mechanism in the configuration. If the mechanism is not the same, the pasword is set again but now with the new mechanism.
I created a small patch for this, does it sound sane? If so, I'll send a pull request with the code. -- Mike
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
-- Martin Gruner Senior Developer R&D OTRS AG Europaring 4 94315 Straubing T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/ Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel Einfache Planung, bessere Übersicht - Mit OTRS 3.3 einfach besseres Service Management - Jetzt downloaden und testen