Why don't we expire passwords on the web?
mrspeaker.net
mrspeaker.net
Quite often in companies I work for, forced expiration leads to passwords written on post-its, because people cannot follow the pace.
Maybe having a biometrics authentication coupled with some kind of 1password would be better!
And it's not the 'writing down' part that's a security risk, it's the 'storing in an insecure location' that is. Password in wallet, fine. Password post-it stuck to monitor, not fine.
http://www.guardian.co.uk/technology/2008/nov/13/internet-pa...
Honestly, if someone has broken into my home, my password to HN will probably be amongst the least of worries (and lowest on the list of priorities for the thief to pick up - I'll loose my computer before I loose the password).
Biometrics are only useful if the remote database and the transmission path is secure. If not, they can re-create & retransmit the biometric hash much like they do your password.
At the place I work at, most everyone just changes their password monthly like: "password1", "password2", etc.. Anything more difficult than that then they are likely to forget their password.
Another awful idea is locking people out if the password is wrong after 3 attempts. Then you have mischievous characters entering in 3 bogus passwords just to lock you out of your account and inconvenience you.
The whole concept of expiring passwords should be gotten rid of everywhere.
So his method is: For every domain use separate password which you can simply generate in your head every time you need to log in. For example by the formula f(domain_name)
Ex:
f(domain_name) = "abc"+first_and_third_letters(domain_name)+"123";
f(google) = "abcgo123"
This way if one site you use is hacked and your password stolen, they can't get to any other of your data online.
Edit: If they compromised one of his other accounts...
1 - can it be easily reverse engineered if somebody gets their hands on 2 of your passwords?
2- use a different formula for banking and other highly secure sites.
The above formula fails the 1st test, but it's easy to tweak. Here's another formula:
first 4 letters => the 4 letters to the right of the first letter of the domain name on a qwerty keyboard, wrapping as necessary. the number "3" last 4 letters => the 4 letters to the right of the third letter of the domain name.
So for google the password would be:
hjkl3pqwe.
ycombinator would be:
uiop3pqwe
et cetera.
Make sure you have a number in your formula, so you don't get thrown by sites that require a number.
P.S. the formula I use is much different from that described. :)
Generally, users come and go. We accept them as engaged, contributing users when they preform an action once every x number of days. Expiring passwords is one more hurdle that must be crossed when a user returns. Any hurdle, even an "email me a login link" will force a percentage of users to re-evaluate their desire to contribute.
People will learn that using one password multiple times has serious repercussions. Already, we're seeing the proliferation of standalone password managers and easy to use bookmarklettes such as SuperGenPass.
I think that the solution to this problem is: Any time that a user requests a new or renewed password, e-mail them a link to a trustworthy, cross platform password manager. Explain that you have no affiliation with the company you're mentioning, but in a short sentence or two, convey that using a strong, unique password is important for their security across the web.
If you leave browsers logged in, it might be a little more so, but still, I want to log in now. Not in a half an hour after the email works its way through my company's spam filters.
The "something you have" only really works as an additional authentication factor to the "something you know" of the passwords.
You wouldn't even need to make it only work for a single login. Let it live for a year or forever. Automate the bookmark procedure for them as well, so their bookmark for your site (https, of course) would automatically log them in, as it would contain a very large random string that identifies them. For extra points on sensitive sites, tie that random string to their IP address, so it only works from the IP address they were at when they first clicked it. If they click it from a new IP address, an email is sent, asking permission to whitelist that IP address for them as well.
Sites that do ask for extra info (Mother's maiden name type of thing) are protected against this, but there are an awful lot of sites that never ask you for anything but an email address and a password when signing up.
UW-Green Bay (where I went) has the same policies as UW-Platteville but has a remote reset page requiring your Student ID, SSN, and DOB.
A great solution would be to have what is, essentially, OpenID, but verified by your email provider. You enter your email (instead of a URL), and get sent to your email provider for authentication. Nobody forgets their email...
Regardless, what's a good alternative now?
Both technical documentation and soft documentation ranging from how end users should interact with it, and what the best practices are. This seems to be an Achilles heel of a lot of projects like this in various patterns regarding informing users how to use it, versus how developers can develop for it.
Just set up your browser to sync passwords, then generate random strong passwords and store it. It'll sync to your other browsers and you're good to go, until you use a browser that isn't your own. And if you're really using those sites from computers you don't own, you have other problems to work out first.