in reply to real time server side validation

yakoval:

Normally, you don't want to give any hints to malicious individuals, so don't tell them which field they have wrong. Otherwise it's a simple matter to harvest the usernames for a site. Normal practice is to simply tell them that their login is incorrect.

Secondly, you don't want to give them a nice tool for breaking your site (the bit you can with AJAX). So on the server side, be sure to put a time delay between login attempts, and possibly[1] lock the account after a few bad login attempts. Again, to prevent giving any clues, you probably don't want to tell the user that the account is locked. (Except by EMail, if they've registered an EMail address.)

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Update: [1] As JavaFan notes, it's not necessarily a good idea to lock the account.

Replies are listed 'Best First'.
Re^2: real time server side validation
by chrestomanci (Priest) on Dec 14, 2010 at 09:26 UTC

    Agreed

    Further to that, I would also suggest that you block or slow down the IP address, after a certain number of failed login attempts from the same address, as otherwise, a cracker could try the same password with a long list of Different usernames, in order to try to break in that way.

    If I where you, I would impose a 1 second delay between login attempts for the same username or from the same IP address block, and after 3 failed attempts, I would double the delay for each subsequent failed attempt up to a maximum of around 5 minutes.

    I don't think there is anything to be gained from using AJAX or suchlike to check usernames & passwords in real-time. As roboticus said, that would just make cracker's job easier, and also give them a way to overload your server and inflict a denial of service attack. A simple form submit with both a username and password on it should be sufficient.

    One thing you might consider, is to use JavaScript on the client to hash the user supplied password with a random salt string supplied by the server, so that if the password submission form is intercepted over an insecure WiFi or suchlike, a cracker will not be able to re-use it later.

[reply]
      Thanks for your comments. But if we put aside a security part and take a real user (not a cracker) - which made a mistake (or forgot username (password)) while trying to sing in to his account. I have to say him "The username or password is incorrect. Please try again." Maybe the simplest way in such case to redirect a user to another page with the same fields (username and password) with a message about incorrect data?
[reply]
Re^2: real time server side validation
by JavaFan (Canon) on Dec 14, 2010 at 17:00 UTC
    So on the server side, be sure to put a time delay between login attempts, and lock the account after a few bad login attempts.
    And give attackers an easy denial of service attack? (Deny our customers service -- no botnet needed!)
[reply]
Re^2: real time server side validation
by yakoval (Novice) on Dec 14, 2010 at 16:39 UTC
    Thank you for advices! They are very useful. But anyway how is such validation implemented at www.hotmail.com or www.gmail.com for example? By using AJAX?
[reply]

      yakoval:

      I don't really know much about web programming, as what little I did was a long time ago in a different language. Hopefully a better-informed monk may have some good insight. It's a common task, though, so I'm sure that there's code code you can leverage from CPAN or the web. If I were approaching a new web programming job, I'd certainly not write my own login and session management code--I'd dig through CPAN and see what's already out there. (In fact, I did a quick search for "Login" on CPAN and it came up with a few likely candidates.)

      ...roboticus

      When your only tool is a hammer, all problems look like your thumb.

[reply]

In Section Seekers of Perl Wisdom