Slow, crashed within minutes of using it. It's not very pretty either. I'll stick with Adium/Jabber hooks but was really hoping for something good here.

Really good idea and execution. Thank you for building this.

Keyboard support for entering a date manually would be great. The GUI is great. Would like to see what the author could come up with for a pick a time.

This. How can you display a time and mean something if you don't know what timezone the user viewing it is in?

It gets even worse with DST. is GMT+2 meant to be Spain in summer, or something else?

Relative dates are a blessing where space is a constraint

"In step 4, never tell the user if it was the username or password they got wrong. Always display a generic message like "Invalid username or password." This prevents attackers from enumerating valid usernames without knowing their passwords."

What prevents the same enumerating attack against the sign up form. Are you going to give them a generic message that the username is invalid when it in fact has been taken?

Also the article implies that you need to use salt but than recommends using bcrypt which already includes salt.

Good read on how passwords are attacked.

This is a point where you'll have to judge the security considerations against usability considerations. As a user I might end up hammering a web service with correct passwords but incorrect usernames. As a user knowing that I'm using the wrong username would be useful and keep me from getting frustrated.

A better solution would be to rate limit incorrect username guesses. It's highly unlikely that a user is going to try more than a dozen usernames/emails - so that's strong signal that someone is trying to leak username information from your database.

It seems to me that a web application should not assist in its own hacking by allowing automated high-speed form submissions.

Why should a form that accepts human input accept input much faster than a human can generate it? Limiting form submissions to about one every second per IP should greatly reduce the value of brute force attacks without being perceptible at all to actual users.

If you're worried that will be too slow for your users, make it a tenth of a second. That should still be far too slow for enumeration or other brute force techniques to be worthwhile.

Surely after say, three invalid attempts, your app should lock the account and/or send an email and/or present a CAPTCHA?

Sure, that would be another way to stop automated enumeration attempts.

"What prevents the same enumerating attack against the sign up form. Are you going to give them a generic message that the username is invalid when it in fact has been taken?"

This is a good point, but I suppose that, all other things being equal, it's better to put the key under the mat than it is to put it on top it. IOW, the more sophistication your attacker needs, the better.

"What prevents the same enumerating attack against the sign up form. Are you going to give them a generic message that the username is invalid when it in fact has been taken?"

There are, more frequently, CAPTCHAs on registration forms.

Immediate username availability checks (via ajax) are fairly common, and they bypass captchas.

> What prevents the same enumerating attack against the sign up form.

Good point. Nothing prevents this, but it is easier to detect this kind of abuse on the sign up form and alert on it than all of the noise on the sign-in side.