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

Password leaks bigger than first thought

h-online.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Password leaks bigger than first thought

#31

Post by latchkey »

zizee wrote: post #28
latchkey wrote: post #25

Earlier quoted context omitted.

Nope. Feel free to play around and try it yourself. I think the experience is not 100% perfect but is pretty darn good. That said, I'm always open to constructive feedback. www.voo.st

Looks nice. My biggest feedback is that there is no "Join now" link/button, just a login. I presume that if you try and login without an account it will go ahead and sign you up, but it is not obvious. Also the line "All events on Voost are managed by an organization " - I'm not sure what that means, what is an organisation ? Is that me?

Great feedback, thanks. The button is 'sign in' since we don't really need the concept of login. Adding another button seems more confusing, what would it do?

As for the text, sure, we can work on clarifying that more.

Re: Password leaks bigger than first thought

#32

Post by zizee »

latchkey wrote: post #31
zizee wrote: post #28

Earlier quoted context omitted.

Looks nice. My biggest feedback is that there is no "Join now" link/button, just a login. I presume that if you try and login without an account it will go ahead and sign you up, but it is not obvious. Also the line "All events on Voost are managed by an organization " - I'm not sure what that means, what is an organisation ? Is that me?

Great feedback, thanks. The button is 'sign in' since we don't really need the concept of login. Adding another button seems more confusing, what would it do? As for the text, sure, we can work on clarifying that more.

Having two buttons doing the same thing wouldn't necessaryily be confusing. People would probably not notice.

Or how about change the wording to "sign in/up".

Re: Password leaks bigger than first thought

#33

Post by jacktoole1 »

zizee wrote: post #29
waffle_ss wrote: post #7

Unsurprising that >95% of the password hashes have been broken. I remember being annoyed when I signed up for LinkedIn (just checked my tweet history - it was 2010/06/10) because they were only allowing 16 characters in the password field. EDIT: Whoops, guess I should have done some napkin math before claiming that there are rainbow tables that cover that area. /me slaps wrist

But still a good point: Why limit your password length? My online banking is the worst offender that I know. Not only do they insist that the password is no longer than 8 characters, it HAS to be 8 characters. Madness!

I agree, banks having this flawed security is quite frightening!

My bank used to have an 8 character password limit policy, but recently changed it (without announcing it), and I was able to use a 20+ character password. It's worth re-trying once in a while just to be sure.

Re: Password leaks bigger than first thought

#34

Post by mutagen »

zizee wrote: post #26
lucian1900 wrote: post #4

Earlier quoted context omitted.

I guess the more you have, the more information you have about the salt used. I'm not sure it'd be useful though. And many of these hashes aren't salted anyway.

Often people will store the password salt alongside their password hashes*, so if someone has the user table they would have the salts. --- At Authic.com we are investigating the practicalities of storing salts in a separate database from the password hashes.

Doesn't that still leave the door open to database compromise?

What are the practicalities of distributing the system among various technology stacks, minimizing the damage caused by a 0day or single engineered attack vector? Really thats just security by obscurity and the solution should be a robust system to begin with but I'm wondering about anticipating the human mistakes that render an otherwise secure system into a series of news articles like we're seeing.

Re: Password leaks bigger than first thought

#35

Post by cheald »

zizee wrote: post #16

What do people think about outsourcing your authentication to someone else? Full Disclosure: I'm currently working on a brandable authentication host ( http://www.authic.com ) that will outsource the pain of storing your password hashes securly and provide your web app with slick a user account UX.

We all do it daily with Facebook et al delegated authentications.

Re: Password leaks bigger than first thought

#36

Post by terangdom »

duskwuff wrote: post #22
rpearl wrote: post #19

Earlier quoted context omitted.

I mean... there are surely not rainbow tables that span all 62^16 16-character passwords consisting of alphanumerics only: that is 646,081,519 zettabytes of hashes (62^16 * 128 bits). There are clearly rainbow tables which span a more useful dictionary of passwords, though--and certainly all the most common passwords.

Even if we conservatively assume that you only need lowercase characters, and that you need one bit per password, that's still 26^16 bits = 4.6 ZB, about fifteen times the total capacity of every hard disk sold by Seagate in 2011 (330 EB).

They usually use less than one bit per password.

Re: Password leaks bigger than first thought

#37

Post by zizee »

mutagen wrote: post #34
zizee wrote: post #26

Earlier quoted context omitted.

Often people will store the password salt alongside their password hashes*, so if someone has the user table they would have the salts. --- At Authic.com we are investigating the practicalities of storing salts in a separate database from the password hashes.

Doesn't that still leave the door open to database compromise? What are the practicalities of distributing the system among various technology stacks, minimizing the damage caused by a 0day or single engineered attack vector? Really thats just security by obscurity and the solution should be a robust system to begin with but I'm wondering about anticipating the human mistakes that render an otherwise secure system in…

Doesn't that still leave the door open to database compromise?

Well, if you have it in the same DB table you are still at the mercy of database compromise. Better would be to store the salts in a separate table from your password hashes. Better yet, store it in a different database. And even better, store it on a different server.

What are the practicalities of distributing the system among various technology stacks, minimizing the damage caused by a 0day or single engineered attack vector?

Yes, having the salt in a different type of db from the hashes adds protection from zero day exploits exposing one brand of db. A combo of NoSQL and SQL seems logical.

Really thats just security by obscurity

Security through obscurity is not a bad thing, as long as it is not the only measure you are taking. But anyway, you need to have security through obscurity - or are you suggesting that making your salts and hashes publicly accessible would be ok? Or is it a good idea to obscure it?

and the solution should be a robust system to begin with

Of course, you should do everything possible to make system secure. A big part of this is to try to minimize the number of single point of failure attack vectors.

but I'm wondering about anticipating the human mistakes that render an otherwise secure system into a series of news articles like we're seeing.

Well, a lot of these news articles could be lot less worrying if people were salting their password hashes properly.

Re: Password leaks bigger than first thought

#38

Post by terangdom »

chrischen wrote: post #9

"The API was developed 9 years ago, and appears not to have been updated since." Last.fm could have updated this, except it would have meant making all their users do something.

Why not use lazy rehashing? On login, the password is availible and so can be rehashed properly.

Re: Password leaks bigger than first thought

#39

Post by cheald »

zizee wrote: post #26
lucian1900 wrote: post #4

Earlier quoted context omitted.

I guess the more you have, the more information you have about the salt used. I'm not sure it'd be useful though. And many of these hashes aren't salted anyway.

Often people will store the password salt alongside their password hashes*, so if someone has the user table they would have the salts. --- At Authic.com we are investigating the practicalities of storing salts in a separate database from the password hashes.

Just use a hardcoded application salt (significantly large, >128 bytes is more than enough) in addition to your per-user salt (stored in the DB, or derived from a DB field). That way, an attacker would need both code access and DB access to crack the hashes, and if that happens you're basically screwed beyond redemption anyway.

Re: Password leaks bigger than first thought

#40

Post by getsat »

Havoc wrote: post #30

Unsalted hashes. Wow. What a bunch of amateurs. Also, 10 internet points says at least one other major website will fall too within 2 weeks. Someone has found a new exploit & is trying various sites & collecting hashes.

It doesn't really matter if you're salting or not when you use really fast general purpose hashing functions. Consumer video cards can calculate half a billion SHA/MD hashes per second nowadays. You're talking minutes vs seconds. Unacceptable.
Post reply on HN