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.


WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to