Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Password Security The Right Way

stormpath.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Password Security The Right Way

#41

Post by peterwwillis »

Every time I read "military-grade" on one of their pages, my head twitches. Since your whole product hinges on HTTPS, you might want to tweak a couple things:

1. Disable TLS compression. (it's currently on)

2. Disable CBC-based ciphersuites. (they're currently enabled, or higher priority than RC4)

3. Get more than one IP address to host your site, preferably distributed to a different part of the world. It seems you've got two separate amazon IPs, one for www.stormpath.com and one for stormpath.com; i'm not sure if those are anycast addresses but I doubt it. I really hope they're not in the US East/Virginia zone, since it goes down about once a year (which makes your 100% availability guarantee for enterprise customers impossible)

4. Your main cert has SANs for stormpath.com, www.stormpath.com, api.stormpath.com, ci.stormpath.com, repository.stormpath.com. I know that makes it easier to manage, but when one of these hosts gets compromised and its private key stolen, the whole kit and caboodle is compromised.

5. Implement DNSSEC and IPv6. Your public sector clients will get a kick out of it.

Re: Password Security The Right Way

#42

Post by peterwwillis »

Retric wrote: post #39
peterwwillis wrote: post #31

Earlier quoted context omitted.

What the fuck are you talking about? A salted password is not two-factor authentication and bcrypt definitely helps people using 'p@ssw0rd'. This is the worst troll ever.

If you don't know the salt you can't crack the password. So, if say your backups are compromised and someone has all the user names and passwords they still need the salts before they can login to your service.

Let's completely ignore the fact that most compromises of password databases are of live systems, not extraneous backups. What the hell is the point of the backup? You didn't back up the salts, so restoring the backup leaves you with a broken, useless password database.

Re: Password Security The Right Way

#43

Post by tptacek »

Retric wrote: post #39
peterwwillis wrote: post #31

Earlier quoted context omitted.

What the fuck are you talking about? A salted password is not two-factor authentication and bcrypt definitely helps people using 'p@ssw0rd'. This is the worst troll ever.

If you don't know the salt you can't crack the password. So, if say your backups are compromised and someone has all the user names and passwords they still need the salts before they can login to your service.

If there's some place you can put salts where attackers can't get them, I advise you to put your passwords there too.

Re: Password Security The Right Way

#44

Post by cookingrobot »

Also realize that you don't have to build every component of your website yourself - and unless security is the focus of your business, dealing with storing passwords might not be the best use of your time.

We built dailycred.com to handle exactly these sorts of issues for you.

Re: Password Security The Right Way

#45

Post by tptacek »

peterwwillis wrote: post #41

Every time I read "military-grade" on one of their pages, my head twitches. Since your whole product hinges on HTTPS, you might want to tweak a couple things: 1. Disable TLS compression. (it's currently on) 2. Disable CBC-based ciphersuites. (they're currently enabled, or higher priority than RC4) 3. Get more than one IP address to host your site, preferably distributed to a different part of the world. It seems you'…

You don't need to disable CBC ciphersuites. Implementing DNSSEC and IPv6 will do approximately zero for your security, too.

Re: Password Security The Right Way

#46

Post by peterwwillis »

tptacek wrote: post #45
peterwwillis wrote: post #41

Every time I read "military-grade" on one of their pages, my head twitches. Since your whole product hinges on HTTPS, you might want to tweak a couple things: 1. Disable TLS compression. (it's currently on) 2. Disable CBC-based ciphersuites. (they're currently enabled, or higher priority than RC4) 3. Get more than one IP address to host your site, preferably distributed to a different part of the world. It seems you'…

You don't need to disable CBC ciphersuites. Implementing DNSSEC and IPv6 will do approximately zero for your security, too.

True, you can just give RC4 higher priority. Implementing DNSSEC/IPv6 is just meant to give managers who are obsessed with "military-grade" anything a hard-on.

Re: Password Security The Right Way

#47

Post by stan_rogers »

tzs wrote: post #36

Can we someday move away from password on the server, at least as an option? Give me the option of setting up my account with a public key instead of a password, and logging in by demonstrating that I have access to the corresponding private key. One might object that this would mean I could only access my account from computers and devices where I keep a copy of my private key. True--but I'm ALREADY in that position…

You mean for web apps? Lotus Notes has done that since forever. The Notes password is just the seed of a decryption key for your user ID file; getting the password correct decrypts the keys, both private and secret (used for shared symmetrically-encrypted document fields); the actual server login is PKI. (The Domino web password for HTML apps, when enabled, is a standard hashed-values type, though.)

Re: Password Security The Right Way

#48

Post by jgeorge »

MattRogish wrote: post #37
tptacek wrote: post #35

Earlier quoted context omitted.

Ok just so you know the default cost factor for bcrypt-ruby is a reasonable choice, and the cost factor you've used here is unreasonable.

Absolutely. Was trying (but failing) to make a joke.

BCrypt 19s are <40s to encrypt here, using Java and not even native code. Certainly not outside the realm of usability for something you don't authenticate against all the time. I wouldn't want that for my screenlock password, but I can still see it being workable.

Re: Password Security The Right Way

#49

Post by Retric »

tptacek wrote: post #43
Retric wrote: post #39

Earlier quoted context omitted.

If you don't know the salt you can't crack the password. So, if say your backups are compromised and someone has all the user names and passwords they still need the salts before they can login to your service.

If there's some place you can put salts where attackers can't get them, I advise you to put your passwords there too.

It's not a question of can't just forcing them jump though one more hoop. Ideally, no single employee should be able to compromise your system and doing something as simple as xor'ing passwords with 'bob' goes a long way to prevent DBA's from having easy access to everything. So, from a cost benefit standpoint it's obvious to salt your passwords with something.

Edit: I am honestly surprised how much push-back people are giving this without saying why they actually disagree.

Re: Password Security The Right Way

#50

Post by daeken »

bashzor wrote: post #32
jgrahamc wrote: post #8

I would be very skeptical about dealing with this company... Level 2 ask for a CSPNG to be used to generate the salt. Why? Given that the salt is assumed to be a piece of public knowledge when attacking a system like this there's no need for it to be output from a CSPNG as there's no concern about a random number generator weakness as an attack vector. Level 3 it's not clear if bcrypt/scrypt are used or just some SHA…

CSPRNG*. CSPNG is Collaborative Support Programs of New Jersey :P

Cryptographically secure pseudo-random number generator.
Post reply on HN