Choosing a bad password, the Rebekah Wade way.
blog.jgc.org
blog.jgc.org
And always, after their account becomes compromised, they understand that the bad guys may just want access to resources so they can send spam, or do other illegal things. Sadly, it seems to always take something like this to make the point fully understood and after that the person is fully on-board with password security.
Just my experience.
Passwords make for terrible security. Non-computer folk just don't want to devote the necessary headspace required to do it right. Hell, I handle this stuff for other people all the time, generate on average a few new random passwords of varying lengths every day, have memorized tons of the buggers -- including some rather ugly ones -- and I'm still not doing it right.
No, I don't know what would be better than passwords.
But I'm looking forward to it when it shows up.
Of course, there are all kinds of things I'm not thinking of, because... it's not my area of expertise. It just seems like it might be something that's potentially doable and a decent compromise between security and usability.
So a phone solution sounds like a pretty good solution, since it's not any worse than the current situation. However, a fair number of people still have a 10 cent/message SMS plan, and would be unhappy if they had to start paying $1+ a day to log into all their accounts, so using SMS seems less than ideal in that respect.
To do iris-scanning security, there must be a back-end database with the characteristics ("fingerprint") of each user's iris.
This database will be secured as strongly/effectively as a password database because it contains authentication credentials.
Unfortunately, password databases get broken into, and similarly iris databases will also get broken into.
The attacker then has to simply convert the iris fingerprint back into an image to replay to the authentication process.
This is probably easier than reversing a password hash (because the fingerprinting algorithm is unlikely to be optimised against reversing), and certainly no harder.
(This is assuming untrusted client-side hardware.)
Rather, a good solution would involve deriving a (site-specific) token from the fingerprint and handing it off to the remote service, which then deals with it in much the same way we expect sites to deal with passwords.
This, of course, presupposes that we can retrieve a consistent and unique fingerprint from the same iris from various different images of it, and breaks down if all we can do is check an iris image to see if it matches a fingerprint.
It's not clear how using iris fingerprints rather than passwords really adds anything other than to increase the risk of a false negative, and introducing a third party dependency.
(I do take your point about storing a hash of the iris fingerprint, though. How this would intefere with the matching process is, I guess, outside of both our areas.)
And if you could consistently derive the key from the biometric data entirely on the client, then you wouldn't even need an authentication provider, instead transparently treating the resulting authentication token as a password.
If a password database is compromised, you have a problem, but you can change everyone's passwords.
If an iris database is compromised, you really have a problem.
Biometrics are also susceptible to replay attacks, where sort-of-alternatives (such as tokens) aren't.
Hash + Salt on the client, submit the result. Unique salt for each remote service, and you can change it for a particular remote service if it turns out they do stupid shit with it.
Biometrics are pretty much useless in consumers hands; they're more security theater than anything else. I do mean "pretty much"; if you fiddle around the edges of the problem you can with some work construct a use case where they really are the best solution to a problem, but as something that can just be deployed on a wide scale for general purposes? No.
I'm quite happy with Google's Implementation of http://en.wikipedia.org/wiki/Two-factor_authentication called "2-step verification".
I started this just a short while ago in response to all the Lulzsec email/password combo DB dumps that were released.
In short, you keep an email in your inbox that looks tempting for hackers that - if any images are loaded or links are followed - sends a text message immediately to your phone, allowing you to quickly change your password and/or alert your administrator.
http://blog.jgc.org/2011/06/my-email-canary.html ( discussed at http://news.ycombinator.com/item?id=2636685 )
It's much more probable that they brute-forced it in microseconds from the md5 hash, which is where the actual weakness is. I will go so far as to say that, had they used bcrypt, this would have not been broken, because people don't usually go around gathering personal data about you to try by hand (unless you have the CIA interested, that is, and then they can get in in easier ways).
So, in your case, the last time you heard of anyone guessing a password was about a second ago.
Just curious, but what in particular? Their profile page, logs of forum conversations? And how does he/she generate the guesses? It seems like optimally you'd have some kind of tool which constructs permutations of likely words (sun, 5un, sun!, etc).
...Honestly just curious, promise I'm not planning anything evil.
The back-end could be using bcrypt with a ridiculous work factor, and server security could be state of the art, but choosing your phone number as a password will always be a poor decision.
Always? OK, I've reset my HN password to [one of] my phone number. So you can log in as me now?
No of course you can't. You don't even know how many digits it is, did I include + for an international number, did I use brackets, hyphens, dots (comme une gars Francais)? How will you connect my online ID with my phone number¹?
Once you have my password what are you going to do? Right flames and lose me karma? I can just start a new account if needs be, nothing lost really.
For many accounts a phone number is probably a good enough password IMO. For accounts that handle money? No way. For email accounts that receive reset passwords? Not a chance. For posting drivel on tech chat forums ... it'll be fine!
--
¹ If you can I'd prefer you didn't print it.
Interestingly I searched for the numbers as I'd use them along with a substring of my username and didn't find them. Did you really Google or were you using the term generically? I tried both Google and Bing.
Well done now you can destroy my HN karma (no not really).
The seomoz profile lists a couple of websites. One of those sites has a phone number on the /contact page, and the /about page on the other links to another business (not totally sure how I originally found that, but this is currently the quickest way to get there.)
That business has a couple more phone numbers listed on their homepage, which also matches the phone numbers on the shopfront on google street view.
This can also be cross-checked with whois.
A bit more googling (literally) of your names found an alternative (possibly old?) address in the same town, and googling that pulled up a fourth number.
I never used to give away my location but got tired of anonymity for it's own sake. Think I'll be reviewing my online exposure now. It's been something I've worried over a little recently but it's hard to keep work/home separate (which I prefer) in many ways. Thanks for getting back to me.
I implement this personally by keeping my GPG keypair available, encrypting an email to myself with the relevant login information, and pulling this email up when I need to log in. In most cases it's a simple copy and paste operation and that works great. :)
This is going to be an ongoing problem until someone makes it extremely easy for either one side or the other to implement it correctly. With so many divergent development technologies, I reckon it will be much easier to achieve this kind of safety on the client side than the developer side -- LastPass et al are good steps.
There has to be a compromise somewhere. Users will have to accept one day that if they don't want important digital data stolen, they are going to have to personally become serious about password security, unless someone finds magic "fix every computer system's password storage methodology" dust somewhere. In the meantime, a user is welcome to be reckless and he can see which method he prefers.
I am just saying that every other week there is a new blog post with password analysis of leaked passwords: how many are 123456 and blah blah blah. I think it's time to cut some slack to the users and start blame HEAVILY whoever is taking care of the system or programming the service.
(BTW: you'd be better off using supergenpass or stanford PwdHash)
If the passwords are stolen (as happened here) the passwords are worthless in that they won't give access to any other sites she may have accounts at, including her banking and other sensitive accounts.