Quote from: MBH on June 21, 2011, 09:05:31 PM

smartcardguy,

Account lockout is very frowned upon since it can be used for denial of service. I used to do it to certain abusers on Hotmail before when it employed that method.

Enrolling/trusting certain machines can be useful but also dangerous because if your session/cookie is hijacked, then no password is required and you're immediately impersonated. Personally, I only login from my own devices (laptop or phone) and not anyone else's, but I still wouldn't want to allow for the chance of having a cookie stolen allowing access to my account and enabling other systems as authorized systems.

Regarding passwords & hash salting, BlowFish has a very small footprint on memory (4kB) but dictionary attacks are extremely slow because that's how the crypto was designed (details on Wikipedia). I have a friend who was brute forcing passwords on graphics cards; he was doing 4000 million pwds/sec of MD5, but only 200 pwds/sec on blowfish. See the difference?

That's true, but it depends on the account lockout scheme used and the thresholds applied; those issues can be mitigated to some extent and the technique can even be applied proportionally to the risk, I presume someone would rather have an account with half a million USD of BTC in it locked out on 10 failed password attempts than have that money lost.

As for machine authentication as a factor, when this is done it is just one factor (password + machine key) it does not have the properties of a session cookie which is what you described; additionally when implemented its done with cookies that only go over TLS to that site so while cookies can always be stolen with access to the local cookie store or with use of another attack vector this approach is very effective at mitigating account takeover issues with minimal use experience impact.

I am familiar with Blowfish's security and performance properties

My point was that length a hash algorithm outputs is a consideration in addition to its computational performance characteristics, specifically it has bearing on the time-memory trade-off problem; see http://en.wikipedia.org/wiki/Rainbow_tables.

No system that needs to authenticate users should store a flat hash, they should all salt.