On 28 December 2010 21:18, Dotan Cohen <dotanco...@gmail.com> wrote: > On Tue, Dec 28, 2010 at 21:57, Nathan Rixham <nrix...@gmail.com> wrote: >> Don't trim or limit the range of input characters, but far more importantly >> /don't send passwords in clear text/, indeed don't generate passwords at >> all, let users enter there desired password, then they won't be copy and >> pasting them ;) >> >> ps: if unavoidable, then give some advice on "login" failure like "passwords >> are case sensitive, check you don't have caps lock on and that you haven't >> included any additional spaces". >> > > I'm toying with the idea of having the passwords hashed twice: they're > already in the database hashed, and javascript hashes them on the > client before sending them over, but I'm thinking about sending an > additional salt to the client to hash the hashed passwords with salt, > and that's what is sent back. This way, each login is done with a > different hash of the password so an attacker cannot simply capture > and reuse the hashed password.
Sounds like https would be MUCH simpler and likely as safe or safer. I wouldn't waste my time on trying to come up with very clever schemes when tried and true technologies are out there. > But before all that goes on, I have to decide what to do about leading > and trailing spaces. As has been noted a couple of times: trim usernames. Never trim passwords. Regards Peter -- <hype> WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 </hype> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
