> While my opinion of you is not favorable, I do believe that we should > always look at reports without seeing who filed them and react > accordingly.
duly noted. > The option for 'hashed' does what you are talking about, and the > documentation clearly lists the differences here. Yes, well I don't see this "clearly" communicated here. In fact, for me, I don't see the "difference" at all -- so maybe you can rub this off as a doc bug. I've never heard of Crypt::SaltedHash prior to today, and had no idea of what it does. However, I'm very familiar with salts, and hashing. I also see little reason to indicate 'salted_hash', should be chosen over 'hashed', w/ salted attributes. When I was reading the docs, I saw "Digest", and mention of salts, and figured that was what I as looking for. This could have been my error. > I'm more of the mind that this is a non-issue, but could easily lead > people astray into doing something that they do not want to do. If > there is a problem with the way the salts are handled, that would be a > problem in Crypt::SaltedHash. I disagree, reviewing Crypt::SaltedHash, which I wasn't speaking about: it simply serializes the salts and hash(salt . password). Here, I just store in the DB the salt un-serialized with the hash of the salt and the password. I'm not sure my approach is better, or worse; but, I've been doing it for a long time and it is a wide spread practice. After, all the only thing we're doing with salts is stopping a rainbow table attack. Like, t0m I've patched this. In my patch I add two fields which read the user-object. So long as the salt isn't global, but user-specific it will work. Salting a pkid certainly works, and so does storing a random number. Arguably, there are benefits to both sides, and both should accomplish the task effectively. I personally feel, as if someone confused my method (not, that I did it first) when they implemented this pre_salt in config stuff... I'd guess I'm not the only one that has been confused by this. People who use salts the way I've always done them are very likely to read into it and think that the 'hashed' is the best match for them. > Your bug report does seem to imply it would be a problem with > Crypt::SaltedHash, though, which is why without a more thorough > glance, you look like you are wholly mistaken. I don't think anything implies Crypt::SaltedHash in my bug report -- if it did it was a miscommunication. Sorry, I'm not speaking about it at all. Furthermore, after reviewing it seems like a perfectly good solution however different and less-portable it is. Thanks for the reply. -- Evan Carroll System Lord of the Internets http://www.evancarroll.com _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
