It was meant as a way of pointing out how you should do password security. I picked on pg just to enrage people on this site. Password security isn't hard but even the gods get it wrong sometimes.
Pity no one has pointed out that HN logins are not encrypted.
Well I have my 'who cares' password, my 'like this site' password and my 'involves money' password(s). Strangely, my HN password isn't the same one I use for my bank account.
Historically passwords have often been truncated at 8 bytes, so that if the first 8 characters are equal the password is equivalent. This might bite you if you always add on to the end of a long base password like this. Perhaps a variable prefix instead of a suffix?
No. I simply have a different password for every site. I use a tool called 1passwd to generate and remember all those passwords for me.
That tool backs up its (encrypted) password db to my Dropbox folder. It also backs up to an iPhone app. So I think the chances of losing all my passwords are pretty slim. And, now, I don't care whether one site loses my password, since all my passwords are unique.
In order to lose my passwords, I need to lose, at the same time:
1) my mac mini
2) my macbook pro
3) my iphone
Even then I would be able to recover things somehow, because my email goes through a third-party gateway, and I know the guy who runs it, so if I really do lose everything, I can contact him and ask him to reset my password on that gateway, and then log in to my email via that gateway.
I think the chances of losing my passwords are fairly slim.
No, I have one slightly-convoluted-but-simple-enough-to-keep-in-my-head method of generating a password for a given site based on information about myself and the site along with some transformations.
For important passwords that I might forget, I apply another easily rememberable transformation, and write them down.
I use my bank account password for everything. They'll never predict that. These criminals are sneaky, you've got to use reverse psychology if you want to truly be safe.
On a more serious note, only one of the two websites compared in these articles is a multi-million dollar business. Also, I'd say HN users are far more likely to use throw away passwords. The "enterprise" clients of 37signals probably subscribe to the philosophy in my satire above.
One final note. I don't think you can log into this site over SSL, so a discussion about password security for HN accounts is just silly. What's the point in worrying about how secure the vault is if the front door is unlocked.
I have a unique password for each and every site I'm registered at. Outsourcing the safekeeping of your password to everyone but yourself is a bad mistake.
Seriously, enough with these threads already. The passwords aren't encrypted, he cries about it, they are encrypted, he cries about it. It's a news site, we're not controlling access to nuclear weapons here.
I think the main concern is not that someone can use your account here at HN but the fact that they can get the password file and use your password to access your personal emails and whatever else (assuming that your using the same password, which some people do)
No, I already mentioned that some place else. If you want to get interesting take a look at how unique IDs are generated.
They rely on the Scheme random number generator which is seeded using the milliseconds of Unix epoch. Since PG regularly restarts the server it should be possible to get a window of time in which to test a succession of random number seeds. If you could hang around until the server was dead (say test every few seconds), then login and obtain a cookie you'd have enough to do a prediction of the server seed. You could then run the random number generator forward predicting cookie values and then run them by the server to see which ones are valid.
As people log in you'd be able to impersonate them. Assuming that an admin logged in while you were testing you'd be able to impersonate an administrator and have some fun on the site.
I'd contribute $5 or $10 a year towards SSL via PayPal. Does anyone else care enough about password hijacking to pay a little? Though that might require a hardware upgrade, as well (if the scope extends beyond login to site browsing).
Security on Hacker News is good enough. But, it would be kind of nice to have salted hashes and an absurdly expensive hashing algorithm. We are meant to be hackers after all.
A standard, or even a rationally conservative, approach seems more fit for Innocuous News.
Oh come on now. We're hackers. That means some SHA1 with a little bit of salt does nothing for "Real Security".
"Real Security" would require personal acquaintance with an operator or someone they have trusted. To go down that trust chain, they would sign your GPG key. After that, posting by signing would be only done. And as per due course, you would be expected to have a HN_only GPG key for 'security reasons'.
But security for securitys sake is just wasting resources when it's just a news site, unless you're a crypto-fiend.
As long as HackerNews hashes my password with a semi-modern algorithm, I'm fine. Storing in plaintext / something that can be decrypted is not cool, but sha1 is alright by me.
But an unsalted hash is only better than plaintext if the attacker doesn't know enough/care enough to use a rainbow table. At that point, why do you care if it was hashed or not?
But that isn't nothing. For instance in the case of the reddit lost laptop incident, the information isn't immediately available to anyone who knows how to read a database dump. It has to decrypted which isn't a widely available skill and isn't instanteous even though its tractable.
That's still a smaller subset than the skills required to steal a laptop. Apparently thats controversial though, judging by the downvotes. I'm not suggesting this is how security should be designed, just pointing out that its not totally useless.
I know where you're coming from, your basic nincompoop is breaking into cars and steals a laptop out of the trunk. Perhaps he has absolutely no idea what a password file is, let alone how to crack it with a rainbow table. HOWEVER, he does know how to sell the laptop to a local ask-no-questions pawn shop that specializes in (a) buying stolen goods, and (b) computers.
I suggest that the pawn shop I've just described employs someone with considerably more advanced cracking skills: they receive several stolen phones and computers a day and have a tidy business on the side selling data and stolen passwords to identity thieves.
I made this scenario up to illustrate that if there is valuable data that can be cracked open, the "market" will organize itself in such a way to get ahold of it.
Complex Answer: It depends. If it's compromised, what do I lose? If the answer is an email account, then it's an 'Aww shucks'. That's why I have backups of my address books.
However, if it's "Bank Account Numbers", it's a bit more critical. I do shield myself from that eventuality by using 'more public accounts' with limited funds. PayPal has its own bank, and a whole 5$ more than my balance needs for them. I simply and deliver the money I want them to have.
And sometimes, I could care less if somebody "hacked my account". I'm thinking about news sites and other sites that demand logins to read or post or download files (phpbb).
Think password resets for pretty much every other account of yours. Whether that is HN, Your Registrar, amazon or your bank. I never used to care about my web based email account - but now it's a big deal.
Still allows for brute-force. Distributed.net is bruting (I know that is not a word) approximately 150 billion a second. No one knows what Uncle Sam and other Nation States can do in this regard. So, salt is good, but you still need big passwords (min 72 bits) to keep the big boys out. 6.5 bit-entropy per ASCII char... that means you need at least 11 chars in your password, OK?
If you honestly understand how the internet works, _and_ are concerned about password security, how can you NOT be using a different password on every site? (or at least a throwaway password for accounts you don't care about)
EDIT: I guess the biggest reason would be that you likely haven't discovered the awesomeness that is 1Password yet. http://agilewebsolutions.com/products/1Password . There are probably free alternatives. (EDIT Again: Mac only. There are Windows alternatives too :) )
I bought 1Password as part of one of those Mac software bundles, but still haven't figured out how it's any better than Safari + Keychain's built in password manager. Can someone please explain it to me?
Hashing passwords doesn't add any real security when the server is compromised, the attacker can just take the entire database.
For a news site accounts are used for identification and not for protection of goods or information so it doesn't matter that much anyway. If the admin of the site finds out that the system is compromised, it's pretty easy to just reset all passwords.
I'm relatively confident that the potential uncovering of some news site password doesn't matter for this demographic. This is hacker news, after all :)
Let's see how long it takes the hacker news team to fix!
(Or even some lisp hackers to beat pg with their own patch!)
Three main issues:
1) improper use of hashing. No salt used.
2) sha1 is not the best hash to be using.
3) passwords are not encrypted in the browser. So are sent clear text.
Fixes for issues one and two, are covered in the article...
For issue 3), you can do the hash+salt client side (with js) if SSL isn't feasible.
If you do hash+salt client side, then the final hash is your password essentially, which will be sent in the clear. Anyone sniff the already hashed password to login to your HN account without knowing your actual password.
What you didn't say but might have implied is:
If you have the server challenge the client with a different salt each time it would fix the problem.
Of course SSL also tells you the you are talking to the real server, challenge response doesn't really help that, nor does it stop some stealing your session id and posting as you.
Salts are near worthless since someone who has access to a web app or the source will probably be able to read the salt. The bcrypt recommendation is somewhat good though, but you can never be perfect. Currently in my web apps we use sha1, but we run it through about 10 times, so it slows an attacker down a bit.
If you don't have salt, the more passwords you have, the easier it is for someone to find one password by a dictionary attack. If you have a lot of passwords you should use salt, if you don't have a lot you still expect your app to grow don't you?
Notice how I get better security without any extra effort? That is the joy of not being the only user of your programming language, and that's how you ensure that people do the Right Thing with your data -- make it easy for them.
(I'll also mention that it gets better; with Moose type coercions, I can basically treat the password as cleartext -- the type coercion converts a Str into a Passphrase. To set it, I supply the cleartext password as an initarg when instantiating a user; when changing it, the writer accessor handles the coerciion; when checking it, I delegate to the passphrase's check_passphrase method. A great API with great security, involving almost no effort on my part. <3.)
Apologies for the wording of my comment. What I mean is that you don't have to worry about libraries for languages a lot if you can use the power of your OS ecosystem (especially, *nix one) in your application (considering performance and other limitations).
Under Linux, fork() is implemented using copy-on-write pages, so the only penalty that it incurs is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child.
> " time and memory required to duplicate the parent's page tables "
Performance penalty is fairly significant ( unless it's done up front, i.e. to setup a pool of processes, like Apache's prefork mpm ). So doing a fork() per each request is actually a really bad idea (as is creating a new thread, but that's a whole other rant I have reserved) -- I'd say it's an anti-pattern (in Java world it's the "one thread per connection" Enterprise(TM)(R) idiocy lot of servlet containers do/users to do disregarding ThreadPools and NIO).
Memory penalty really depends on your language and its VM (and it's assuming no memory leaks). I haven't looked at arc + mzscheme, but it's actually a big issue for me at work with Perl right now at my present work (too much functionality was implement as cronjobs invoking Perl scripts which do system() after system() -- vs. doing it as daemons doing xs calls into C libraries).
I'll grant mzscheme and arc are likely lighter weight than Perl and its JIT, but unless you're doing pure C it's only a matter of degree.
HN isn't a commercial site and actively tries to restrict traffic. The advantage of having already made something people want is that you can make non-commercialized sites and limit the growth to the level you find comfortable :-)
Yes it is probably slightly weaker. It would be weaker if there are collisions in the 1-16 character password space for sha1 (assuming a 16 character limit on the password).
My point was that if you already have a lot hashed passwords then you need a way to transition to salted ones and this was a method to do that.
75 comments
[ 3.5 ms ] story [ 139 ms ] threadAs was mentioned last time if someone is downloading your passwords you have bigger problems to worry about than the way you store your passwords.
Pity no one has pointed out that HN logins are not encrypted.
Throw-away password: "ex@mpl3"
Email password: "ex@mpl3p@55"
Finance password: "ex@mpl3p@55w0rd!"
That tool backs up its (encrypted) password db to my Dropbox folder. It also backs up to an iPhone app. So I think the chances of losing all my passwords are pretty slim. And, now, I don't care whether one site loses my password, since all my passwords are unique.
Also, my dropbox is set up on my mac mini too.
In order to lose my passwords, I need to lose, at the same time:
1) my mac mini
2) my macbook pro
3) my iphone
Even then I would be able to recover things somehow, because my email goes through a third-party gateway, and I know the guy who runs it, so if I really do lose everything, I can contact him and ask him to reset my password on that gateway, and then log in to my email via that gateway.
I think the chances of losing my passwords are fairly slim.
For important passwords that I might forget, I apply another easily rememberable transformation, and write them down.
On a more serious note, only one of the two websites compared in these articles is a multi-million dollar business. Also, I'd say HN users are far more likely to use throw away passwords. The "enterprise" clients of 37signals probably subscribe to the philosophy in my satire above.
One final note. I don't think you can log into this site over SSL, so a discussion about password security for HN accounts is just silly. What's the point in worrying about how secure the vault is if the front door is unlocked.
This is the key. You're an idiot if your Hacker News password is the same as that of your email.
Hmm. No, I don't. I only 'cry about it' (in your words) if the passwords are not adequately secured.
They rely on the Scheme random number generator which is seeded using the milliseconds of Unix epoch. Since PG regularly restarts the server it should be possible to get a window of time in which to test a succession of random number seeds. If you could hang around until the server was dead (say test every few seconds), then login and obtain a cookie you'd have enough to do a prediction of the server seed. You could then run the random number generator forward predicting cookie values and then run them by the server to see which ones are valid.
As people log in you'd be able to impersonate them. Assuming that an admin logged in while you were testing you'd be able to impersonate an administrator and have some fun on the site.
A standard, or even a rationally conservative, approach seems more fit for Innocuous News.
"Real Security" would require personal acquaintance with an operator or someone they have trusted. To go down that trust chain, they would sign your GPG key. After that, posting by signing would be only done. And as per due course, you would be expected to have a HN_only GPG key for 'security reasons'.
But security for securitys sake is just wasting resources when it's just a news site, unless you're a crypto-fiend.
i.e. basically none.
I suggest that the pawn shop I've just described employs someone with considerably more advanced cracking skills: they receive several stolen phones and computers a day and have a tidy business on the side selling data and stolen passwords to identity thieves.
I made this scenario up to illustrate that if there is valuable data that can be cracked open, the "market" will organize itself in such a way to get ahold of it.
Complex Answer: It depends. If it's compromised, what do I lose? If the answer is an email account, then it's an 'Aww shucks'. That's why I have backups of my address books.
However, if it's "Bank Account Numbers", it's a bit more critical. I do shield myself from that eventuality by using 'more public accounts' with limited funds. PayPal has its own bank, and a whole 5$ more than my balance needs for them. I simply and deliver the money I want them to have.
And sometimes, I could care less if somebody "hacked my account". I'm thinking about news sites and other sites that demand logins to read or post or download files (phpbb).
Think password resets for pretty much every other account of yours. Whether that is HN, Your Registrar, amazon or your bank. I never used to care about my web based email account - but now it's a big deal.
[Welcome to reddit puns]
I salt MY hashes.
EDIT: I guess the biggest reason would be that you likely haven't discovered the awesomeness that is 1Password yet. http://agilewebsolutions.com/products/1Password . There are probably free alternatives. (EDIT Again: Mac only. There are Windows alternatives too :) )
1. The password generator is a little difficult to get at, but can be accessed in the Keychain Access application.
2. I don't think it works across multiple browsers. This seems to be the main advantage of 1Passwd.
3. Syncs with MobileMe, or you can just backup your keychains.
4. Safari can autofill nearly any form.
5. Multiple logins are stored. If you start typing the first few letters of the username it will autofill the correct data.
For a news site accounts are used for identification and not for protection of goods or information so it doesn't matter that much anyway. If the admin of the site finds out that the system is compromised, it's pretty easy to just reset all passwords.
(Or even some lisp hackers to beat pg with their own patch!)
Three main issues: 1) improper use of hashing. No salt used. 2) sha1 is not the best hash to be using. 3) passwords are not encrypted in the browser. So are sent clear text.
Fixes for issues one and two, are covered in the article...
For issue 3), you can do the hash+salt client side (with js) if SSL isn't feasible.
cu.
What you didn't say but might have implied is: If you have the server challenge the client with a different salt each time it would fix the problem.
Of course SSL also tells you the you are talking to the real server, challenge response doesn't really help that, nor does it stop some stealing your session id and posting as you.
(I'll also mention that it gets better; with Moose type coercions, I can basically treat the password as cleartext -- the type coercion converts a Str into a Passphrase. To set it, I supply the cleartext password as an initarg when instantiating a user; when changing it, the writer accessor handles the coerciion; when checking it, I delegate to the passphrase's check_passphrase method. A great API with great security, involving almost no effort on my part. <3.)
Notice how I get better security without any extra effort? That is the joy of using an operating system.
Under Linux, fork() is implemented using copy-on-write pages, so the only penalty that it incurs is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child.
(from fork(1) man pages)
Performance penalty is fairly significant ( unless it's done up front, i.e. to setup a pool of processes, like Apache's prefork mpm ). So doing a fork() per each request is actually a really bad idea (as is creating a new thread, but that's a whole other rant I have reserved) -- I'd say it's an anti-pattern (in Java world it's the "one thread per connection" Enterprise(TM)(R) idiocy lot of servlet containers do/users to do disregarding ThreadPools and NIO).
Memory penalty really depends on your language and its VM (and it's assuming no memory leaks). I haven't looked at arc + mzscheme, but it's actually a big issue for me at work with Perl right now at my present work (too much functionality was implement as cronjobs invoking Perl scripts which do system() after system() -- vs. doing it as daemons doing xs calls into C libraries).
I'll grant mzscheme and arc are likely lighter weight than Perl and its JIT, but unless you're doing pure C it's only a matter of degree.
Of course, everything is compromise between performance, ease of use, features etc. I'm not arguing with this.
and you could update the database for that easily.
My point was that if you already have a lot hashed passwords then you need a way to transition to salted ones and this was a method to do that.
Yet, here we have a recent, real example of a moderator account on a popular site cracked because a different site wasn't salting:
http://news.ycombinator.com/item?id=595655
I expect it involves checking users' passwords two different ways (with salt, without) for the foreseeable future.