Choosing a bad password, the Rebekah Wade way.(blog.jgc.org)
blog.jgc.org
Choosing a bad password, the Rebekah Wade way.
http://blog.jgc.org/2011/07/choosing-bad-password.html
53 comments
So, there are more and more murmurings about this in comments on posts like this one. I guess I'll kick this one off this time:
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.
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.
> No, I don't know what would be better than passwords.
I'm quite happy with Google's Implementation of http://en.wikipedia.org/wiki/Two-factor_authentication called "2-step verification".
I'm quite happy with Google's Implementation of http://en.wikipedia.org/wiki/Two-factor_authentication called "2-step verification".
And if Mozilla's BrowserID proves as secure as it looks and becomes widespread, we can combine those two and breathe a lot easier.
I don't have the solution, but I have part of it: http://www.emailambush.com
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.
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.
Reminds me of John Graham-Cumming's email canary:
http://blog.jgc.org/2011/06/my-email-canary.html ( discussed at http://news.ycombinator.com/item?id=2636685 )
http://blog.jgc.org/2011/06/my-email-canary.html ( discussed at http://news.ycombinator.com/item?id=2636685 )
It was actually the inspiration. I'd been doing this myself for a while, but hadn't thought about making an actual product out of it. When I saw the incredible response from the HN community to email canary, I realized I should really take a swing at this.
I think phones might be an interesting possibility. Granted, you can lose one or have it stolen, but for most people that's probably less of a risk than using bad passwords that are the same over multiple sites.
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.
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.
If you have a smartphone, chances are your account to whatever is already compromised by the ability to reset via email, unless you are good about signing out of your email application.
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.
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.
I'm thinking something a bit more high tech, like using NFC or Bluetooth so that you have to have the phone in range of the computer.
What would be better than passwords? Public-key crypto. The password/phrase is only used to protect the private key, so there's only ever one password to remember. Of course, validation of the owner becomes the troublesome point here.
[deleted]
I predict that these problems will be finally solved when commodity webcams are good enough for secure retina/iris scanning.
Biometrics might be useful as one component of security. But if someone ever gets a copy of my iris/fingerprint/face etc., they shouldn't be able to log in as me forever. I want a password (or key or something) that I can change or revoke. I can't revoke my retina!
Unfortunately, this doesn't solve the problem:
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.)
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.)
Ideally, you wouldn't store the iris fingerprint itself - that's just as bad as storing a cleartext password today.
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.
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.
The problem with biometrics is that once they are faked, and they can all be faked, You Have Lost. Once I've managed to acquire a picture of your iris (and somewhere in the system one must exist, even if you hash it ASAP I can still grab it straight from the camera if I've hacked your box), what will you do?
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.
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.
You appear to be suggesting that the real security benefit would come from off-loading the authentication process onto a third party, but we can already do that with password authentication by using OpenID / Facebook Connect / whatever.
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.)
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.)
The real security benefit, I guess, is that people don't need to remember any passwords. The biggest weakness of password schemes is that most people choose weak passwords that they can remember, rather than strong passwords. If you could consistently derive a password from biometric data, then that sidesteps the entire issue (there are no "weak fingerprints").
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.
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 you use a biometric fingerprint instead of a password you will soon find that passwords can be changed, but biometrics can't.
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.
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.
Which is why, as I mentioned, you don't store the biometrics. You don't even send them to the remote service.
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.
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.
I'm sorry, but when was the last time anyone heard of anyone guessing a password? Sure, it's a very easy password to brute force, but it doesn't matter that it's the number of the paper, because nobody would have thought to try it, along with the thousands of other things it could be, each spelt in a variety of ways.
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).
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).
I pulled a machine out of a garbage pile once. Booted it up, it required a password, I guessed "password" and it logged me in as the CEO of the company.
So, in your case, the last time you heard of anyone guessing a password was about a second ago.
So, in your case, the last time you heard of anyone guessing a password was about a second ago.
A college student I know likes to play a certain online game. Some accounts have items and status symbols that are valuable in-game, but the accounts are abandoned for years. Some names are even intrinsically valuable (names like "Sun" or something like that). This college student, at least once a month, guesses the correct password for these old accounts based on information the users provided years ago.
That is far cooler than what I did: your friend actually engages in an intellectual exercise, I just got lucky with a guess.
Your story is certainly one to remember though (and lucky that it was a business owner!) I have to say though, it's quite fascinating to watch my friend work. She would make a gifted detective...
>information the users provided years 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.
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.
She doesn't use any tech like that, no. Profile page is one source of information. It happens to be a site where people share a lot of interests and things like that, so there are a number of profile pages. She finds out what they named their possessions, on this account and others. She searches the usernames in other places. A lot of times she also finds or guesses an email address which hotmail deleted years ago, makes it, and then the site sends the password to her new account.
A few jobs ago, I needed to make some copies, but a five-digit PIN had just been put on the machine. Before going and asking anybody, I tried the building's zip code, which worked.
And still this is yet another hacking that has little to do with choosing a bad password but with the use of the wrong algorithm to store it (md5) and poor implementation of security on the server.
Choosing (one of) your phone numbers as a password really is all about choosing a bad password.
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.
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.
>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.
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.
FWIW, a couple of minutes googling found 3 seemingly-valid phone numbers for you.
Ha, I have 4 (actually 5 but I don't remember the twilio one) ... do you want to give me the end digits for confirmation purposes, last 4 digits should be enough.
deleted
[deleted]
Lolz, totally forgot about whois!!
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).
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).
First google hit for "pbhj" is an seomoz profile for a web person person in the UK, which superficially matches the fact that pbhjpbhj has an account on hacker news and their previous comment here had talked about living in the UK.
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.
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.
Nice work courteous and complete. Funny because I usually do this the other way around. I'm not getting the SEOmoz profile high in the SERPs.
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 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.
The point is very very very rarely you actually hear of hacking stories where someone has actually "guessed" a password. Most of the time it's either social hacking or a db dump. Password choice is important to avoid password reuse but I am pretty confident that password guessing is a hugely overestimated risk.
The News of the World scandal going on now is, to some extent, about guessing the password. However, they were guessing passwords like 0000, which probably isn't quite what you had in mind.
Yes the password scheme (MD5) is wrong. However choosing a password that can be guessed is terrible because a human can brute for that, using the best algorithm in the world isn't going to save you if your password is your phone number.
Considering the abundance of improperly implemented password storage schemes, shouldn't users just presume that their password(s) may be stolen and use unique passwords for each service so that damage is minimized in an attack? It's really all about choosing "bad passwords" if the password exists on more than one site. It is just silly to trust others to implement password security correctly -- use throwaway, randomly generated passwords for all third-party services.
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. :)
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. :)
No system will be successful if it depends on what its users ought to do.
This is exactly right. The users are not in a position to understand how easy it is to break passwords.
Someone should tell them. Users must become more educated about the forces that operate in computing if they are going to be able to continue to use computers with any reasonable level of reliability or security.
I understand that, but at the same time no system will be successful if it relies on what developers ought to do, especially with the kind of coders that pass for "professional" in our industry.
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.
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.
This is likely to be a unique password actually, because it's relevant to the service the user was logging into, and it's only 5 chars (many website would not even accept it because it's too short).
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)
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)
Is there a reason one of those is better? They produce more predictable passwords and require me to enter my real password on untrusted machines.
How do you go about fetching and gpg decrypting an email on an untrusted machine?
This is a great way to choose a password. If her password was selected because of the tip line displayed in bold at the top of the page, then this is probably the ONLY site she uses the password for. Assuming the site isn't holding any sensitive information, the most someone could do by accessing her account here is comment under her username.
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.
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.
Why was the salt her name?
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.