code reader wrote: you could take the "prefix" idea much further. ... with the appropriate delimiter, you could reduce the table to use a single field!
That's why I said "where possible and practical." Your description is possible (and is nearly a definition of a flatfile table), but not practical.
having a dedicated column also means you wouldn't need a special treatment for md5 ("no prefix means md5"). you would just initialize the new alg column to "md5" for the existing users when this new column will be added. ... adding one more column, for password hash salt, would round it nicely. now, each algorithm would be free to use or not use the salt in any way it wishes.
This is a good point. If a salt is to be added, then it starts getting in the way to combine so many things into one field (though some applications that rely on a single algorithm do tie the salt and the hash together in the same field in a similar prefix pattern, and IIRC, Unix crypt does the same thing). Once you get beyond two pieces of information, it becomes more hassle to combine things into a single field. Here, you're talking about three items (at a minimum), which would reasonably suggest a need for multiple fields.
if/when changing salt is used, changing it with each login would also somewhat increase the security, because this way, obtaining an old backup copy will only mean something for users who did not log in since the backup was made.
Changing on each login is a bit of overkill since you need to define a login. Is it the beginning of a session, or just when a password is actively entered? I think that changing on each password change (which of course is now a configurable item) makes for a stronger system. At the most, I think it should be when the user actively enters the password. Otherwise, larger boards may suffer an unnecessary performance hit when sessions are started and the hashes are calculated for comparison and then recalculated with the new salt and stored. Not every hash is as nice on the CPU as MD5.
moondream wrote: Some special characters are hashed as html entities in current Olympus if they didn't change that without me knowledge (I read the cvs diffs). the "&" character is hashed as "&" so any password with "&" in it will be incompatible
OK, I see what you're saying. I thought you meant that the MD5 implementation was different, when it's essentially a change to the plaintext. In this case, yes, there will be some translation issues, but for those not using special characters, the hashes should be identical.
phoenix-cms wrote: i use my own encryption on phpbb2 which is basailly md5 / sha1 pending on php version installed. then use of base64 and salt so the stored hash is never the same.
I see the value of being able to opt for SHA1, and of course the merits of salting have been well-discussed in this thread. However, I'm not clear on the value of using base64 encoding. All that does is provide an obfuscation layer, incurring an additional process that doesn't seem to me to be terribly necessary. It may push a few people down the wrong path, but base64 is fairly recognizable to people with a little experience, and decoding it to get the plaintext is trivial.
