MartinTruckenbrodt wrote:Salted passwords area a nice idea on the first look. But IMO it's not possible in real life to make the password salty enough. Users and/or administratos will be annoyed by it!
Salting does not affect users at all, it just changes the ways passwords are stored and verified.
MartinTruckenbrodt wrote:So IMO this feature is not really a good security feature. I think a time limit te renew the password after a configured time period with password history would be a better and much more usefull security feature.
It's easier to forget a salted password.
I am sorry, but you just seem to have no idea how and why salting is used.
MartinTruckenbrodt wrote:As I understand what you mean I think this salting thing has not the effiency which you want to get. This salting thing really would need to have random mechanism. At least a random passphrase for the board is needed created by the initial setup. A random passphrase for every user IMO is not a good way.
If you want to stay in this discussion and provide useful comments, please read up on Password Hashing and Salting.
MartinTruckenbrodt wrote:BTW: What is state of the art for Olympus?
This question is already answered in this topic.
callumacrae wrote:Anyway, I'm against this entire RFC, as there have been no problems so far and it would create backwards compatibility issues.
There are certainly ways to upgrade/change the password hashing scheme while keeping backwards compatibility. viewtopic.php?f=108&t=33231
discusses this partially.
callumacrae wrote:...A random salt for every user is the generally accepted way, and the way recommended by every security expert. Why don't you think it is a good idea?...
you know every security expert's opinion? Great!
For me the salty thing is an alternative for increasing the hash algorhythm. I think it's easier to get backward compatibility with a higher hash algorhythm.
Based on my job's experience I always prefer simplyfied server side solutions.
1. It is totally unclear what "increasing the hash algorithm" is and what a "higher hash algorithm" is.
2. Salting is required in order to make dictionary attacks and brute-force attacks slower.
3. Because of 2. it does not make any sense to use a per-board salt when you can also use a per-password salt.
MartinTruckenbrodt wrote:Another point is stolen data. What's the matter if only the content of the USERS_TABLE has been stolen?
That is a major reason for why we hash and salt passwords before we store them. Again, please read up on password hashing.
callumacrae wrote:A board wide salt would mean that it is possible to rainbow table every single user at the same time. A salt per user would mean that every users has to be rainbow tabled individually - which will take far longer, and is thus far more secure.
MartinTruckenbrodt wrote:if rainbow tables would offer hashes for random strings then we would have really very large security problems!
MartinTruckenbrodt wrote:I think that you will not find a lot of hashes for random strings there.
Such rainbow tables exist for some hash functions.