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

Ask YC: Best Practices for User Authentication

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Ask YC: Best Practices for User Authentication

#41

Post by DaniFong »

tptacek wrote: post #39
DaniFong wrote: post #38

Earlier quoted context omitted.

Sure, it's not meant to be foolproof. I only wanted sometime to secure the login for the large number of sites taking passwords with plaintext. Right now it's completely a statistics game -- you can just stand outside someone's wireless network capturing packets. If it's insecure or WEP, you'll be able to recover the key, then grepping through with password=_ will eventually give you a password to use on their favori…

This is why app developers should be using SSL. I have no smart-assed responses to an HTTPS login screen. No ad hoc hashing schemes required.

By the same logic, crackers shouldn't attack anything. But they do.

Re: Ask YC: Best Practices for User Authentication

#42

Post by DaniFong »

thaumaturgy wrote: post #40
tptacek wrote: post #12

Earlier quoted context omitted.

This is a win because, even though you're sending something password-equivalent over the wire, at least you're not exposing a password that's used on other applications?

Can we have it both ways? Transmit a password-equivalent over the wire, without compromising the security of the password database? How about using a cryptographically strong hash on the client side, transmitting that hash to the server, and then having the server perform another cryptographically strong hash on the hash it receives, and compare that against its database? This way, the server isn't storing the passwo…

Yes, that is what I suggested.

Re: Ask YC: Best Practices for User Authentication

#43

Post by tptacek »

DaniFong wrote: post #41
tptacek wrote: post #39

Earlier quoted context omitted.

This is why app developers should be using SSL. I have no smart-assed responses to an HTTPS login screen. No ad hoc hashing schemes required.

By the same logic, crackers shouldn't attack anything. But they do.

I'm not sure I see how that follows.

But to reify this a bit, do a little Google research on what the banking industry is dealing with regarding multifactor authentication. Nothing they are trying is working, and they're doing considerably more than Javascript hashing. The schemes being discussed here are being attacked, successfully.

Re: Ask YC: Best Practices for User Authentication

#44

Post by DougBTX »

brfox wrote: post #22
tptacek wrote: post #9

No security scheme delivered over Javascript is going to make a difference in a security audit. Your auditor is going to tell your prospective customer that anybody who controls the DNS, routing, the network, ARP, the browser --- or 10 other places --- can rewrite the Javascript in transit. If you can't do SSL, just do plaintext passwords. It means you're being open with your users about the risk.

I'm no expert... but what if just the javascript was served via https? Maybe somebody ought to put an MD5 javascript library on an https server as a public service. Or would js hashing still be vulerable since the man-in-the-middle could change the nonce or something?

You can inject JS into the HMTL directly.

Re: Ask YC: Best Practices for User Authentication

#45

Post by DaniFong »

tptacek wrote: post #43
DaniFong wrote: post #41

Earlier quoted context omitted.

By the same logic, crackers shouldn't attack anything. But they do.

I'm not sure I see how that follows. But to reify this a bit, do a little Google research on what the banking industry is dealing with regarding multifactor authentication. Nothing they are trying is working, and they're doing considerably more than Javascript hashing. The schemes being discussed here are being attacked, successfully.

Not every app developer who could use SSL does, which can give away passwords shared with SSL sites.

By the same token, some hackers capable of cracking do so, though they, in some sense of the word, really shouldn't.

We're thinking about security from two different standpoints. If I lock my door, but my glass window has no bars, I'll still say it's more secure than a house with a door open. The issue, for me, is less that someone can, but whether someone will. If I make it harder for someone to mess with me, maybe they won't.

Re: Ask YC: Best Practices for User Authentication

#46

Post by thaumaturgy »

DaniFong wrote: post #42
thaumaturgy wrote: post #40

Earlier quoted context omitted.

Can we have it both ways? Transmit a password-equivalent over the wire, without compromising the security of the password database? How about using a cryptographically strong hash on the client side, transmitting that hash to the server, and then having the server perform another cryptographically strong hash on the hash it receives, and compare that against its database? This way, the server isn't storing the passwo…

Yes, that is what I suggested.

Ah, I didn't initially read it that way.

It still leaves the problem of password sniffing over an unsecured network, but I think that could be solved by generating a salt on the server for each login request, and then transmitting that salt to the client, where it's used to re-hash the password-equivalent. That would also help protect against something like a DNS compromise, since effectively every user's password changes every time they log in.

There are still plenty of ways to break this scheme, but I think at this point it's Sufficiently Hard (tm) enough to be suitable for an online forum.

...and I imagine that somewhere, tptacek is screaming, "Just use SSL!"

Re: Ask YC: Best Practices for User Authentication

#47

Post by DaniFong »

thaumaturgy wrote: post #46
DaniFong wrote: post #42

Earlier quoted context omitted.

Yes, that is what I suggested.

Ah, I didn't initially read it that way. It still leaves the problem of password sniffing over an unsecured network, but I think that could be solved by generating a salt on the server for each login request, and then transmitting that salt to the client, where it's used to re-hash the password-equivalent. That would also help protect against something like a DNS compromise, since effectively every user's password ch…

I mean, there are a few standpoints here: if you're running a site, use SSL, if you're a user, don't reuse passwords or use something like PWDHash, or if you're working on a browser or you're an admin, consider a way, like PWDHash, of making it so that a password compromised at one site doesn't compromise any others.

Re: Ask YC: Best Practices for User Authentication

#48

Post by tptacek »

DaniFong wrote: post #45
tptacek wrote: post #43

Earlier quoted context omitted.

I'm not sure I see how that follows. But to reify this a bit, do a little Google research on what the banking industry is dealing with regarding multifactor authentication. Nothing they are trying is working, and they're doing considerably more than Javascript hashing. The schemes being discussed here are being attacked, successfully.

Not every app developer who could use SSL does, which can give away passwords shared with SSL sites. By the same token, some hackers capable of cracking do so, though they, in some sense of the word, really shouldn't. We're thinking about security from two different standpoints. If I lock my door, but my glass window has no bars, I'll still say it's more secure than a house with a door open. The issue, for me, is les…

I can't win that argument; it's semantic. Just remember that the majority of the decision you're talking about belongs not you but your users. Don't offer a false sense of security.

Re: Ask YC: Best Practices for User Authentication

#49

Post by johnm »

tptacek wrote: post #34
johnm wrote: post #25

In practical terms, just use HTTPS with rooted certs. It's not expensive for basic usage. And, if you're just doing a for-fun project you can always use self-signed certs. If you want to go deeper down the rabbit hole check out SRP: http://srp.stanford.edu/ In terms of dealing more securely with data on your server, check out the book, Translucent Databases ( http://www.amazon.com/Translucent-Databases-Peter-Wayner/d…

Stay away from SRP. Browsers don't support it natively, and there are (so far as I can tell) no peer-reviewed libraries for it for the major web stacks. SRP is easy to get wrong.

I did say to use SSL in practice, right?

Reading about SRP would help solve much of confusion people seem to be having in many of the discussions going on in this thread.

Re: Ask YC: Best Practices for User Authentication

#50

Post by brfox »

tptacek wrote: post #33
ComputerGuru wrote: post #26

Earlier quoted context omitted.

He means someone set up a a JS library over HTTPS on a server for _others_ to use. Like you would grab a JS library off of Google's HTTPS servers and use that on your non-SSL pages.

Uh... and the page that includes the JS, which is part of your app... comes from where?

Oh yeah, good point!
Post reply on HN