Can you trust Paul Graham with your password? | Hacker News Reader

Can you trust Paul Graham with your password?

jgc.org

65 pointsMaysonL74 comments

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.

Exactly my strategy, too. Anyone else do this?

I hope everyone does this.

Yes, but I've basically only have one password that shrinks depending on how sensitive the information is.

Throw-away password: "ex@mpl3"

Email password: "ex@mpl3p@55"

Finance password: "ex@mpl3p@55w0rd!"

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.

what's your Dropbox password?

That's stored in my iPhone backup.

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.

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.

But which one do you use for email? where you can send resets for everything except the bank (I assume).

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)

"assuming that your using the same password, which some people do"

This is the key. You're an idiot if your Hacker News password is the same as that of your email.

Agreed, thats why mines different :)

"The passwords aren't encrypted, he cries about it, they are encrypted, he cries about it."

Hmm. No, I don't. I only 'cry about it' (in your words) if the passwords are not adequately secured.

And the fact there is no SSL?... (Anyone can snoop your HN password in transit anyway)?

I guess you've found the next installment of the series.

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.

Well, I'm sure you could find a gazillon race conditions. And you know what ? Most of the time it doesn't matter.

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).

This is what's nice about using languages with libraries. If I want to do an unsalted SHA-1, like news.yc, I would write:

    use Authen::Passphrase;
    my $pw = Authen::Passphrase::SaltedDigest->new(
        algorithm  => "SHA-1", 
        passphrase => "passphrase",
    );

If I instead wanted to be secure, and use bcrypt (which I always do, even for the most trivial sites), I would just write:

    my $pw = Authen::Passphrase::BlowfishCrypt->new(
        cost        => 8, 
        salt_random => 1,
        passphrase  => "passphrase",
    );

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.)

Don't you think (system (+ "openssl dgst -sha1 <" fname)) can be as easy replaced with (system (+ "bcrypt whatever_parameters <" fname))?

Notice how I get better security without any extra effort? That is the joy of using an operating system.

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).

If it was just as easy, why wasn't it done?

Doing system requires forking your entire interpreter/VM. That's a huge performance penalty.

There is performance penalty, but come on:

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)

> " 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.

Well, as you can see, HN serves a lot of traffic and has a system() call :-)

Of course, everything is compromise between performance, ease of use, features etc. I'm not arguing with this.

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 :-)

I'm predicting a long line of "Can you trust X with your password" link bait posts.

As was mentioned last time if someone is downloading your passwords you have bigger problems to worry about than the way you store your passwords.

I think this was meant as a poke at the previous article, not a serious critique of HN's security.

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.

You should not trust anyone with your password.

I think you mean "You should not trust _anyone_ with your password".

Maybe he meant "You should not trust anyone with your password."

Shortened version is simply "Trust No One".

Thrust!

[Welcome to reddit puns]

The flavour of the 37Signals comments was very harshly against 37S, these are mildly to strongly in favour of HN.

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

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?

It generates secure passwords. It syncs passwords for all browsers. It creates backups. Autofill for credit-card data. Multiple logins per site.

Actually, Safari + Keychain does most of that:

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.

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.

I'd prefer Off-The-Record encryption over GPG. I want plausible deniability.

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.

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.

Being able to read the salt doesn't make it worthless, because salts are meant to complicate dictionary attacks.

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?

So what's the best way to migrate a site that's using sha1 without salts to one that does use salts?

I expect it involves checking users' passwords two different ways (with salt, without) for the foreseeable future.

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?

If the attacker wanted my password that bad, they would be at my house and I wouldn't be on HackerNews.

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.

Rainbow tables require script-kiddie levels of expertise.

i.e. basically none.

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.

I'm thinking that a salt could be retro fitted by changing the check from: sha1($password); to sha1(sha1($password) . $salt);

and you could update the database for that easily.

Isn't there some evidence that hashing a hash is cryptographically weaker?

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.

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 :)

This article also completely ignores the fact that you can use OpenID to log into HN which bypasses this issue altogether.

Ok, now go visit all open source web apps and post here, you can even write a script for that.

My password is a hash created by 1Password. Plus this is a low value account.

I gotta admit, that does seem a bit lacking.

I salt MY hashes.

Django salts my hashes. It is one of the many virtues of working with a mature framework.

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?

I usually use a minimum of 16 for anything that isn't throwaway.

Simple answer: No.

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).

Primary email account is a loss though...

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.

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.

cu.

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.

Reply on news.ycombinator.com