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

I mean, why not tell everyone our password hashes?

theobsidiantower.com

Post reply on HN
Print view View original

91–100 of 167 posts

Re: I mean, why not tell everyone our password hashes?

#91

Post by developer2 »

cestith wrote: post #37
developer2 wrote: post #18

One reason: you'd be surprised how many companies allow entering the hash as an alternative password to login to customers' accounts in production. Lazy method for customer support teams who don't have support tools to access customer information. Also frequently done to allow developers to debug problems on a customer's account when a bug cannot be reproduced elsewhere. If such a company's database of hashed passwor…

What would it take to get you to name and shame? That whistle pretty likely needs to be blown on the one that didn't agree to abandon such a policy.

Small private company, nobody's ever heard of it. There are a lot of shady ones out there.

Re: I mean, why not tell everyone our password hashes?

#92

Post by [deleted] »

clarry wrote: post #73
komali2 wrote: post #62

>whois -h whois.ripe.net DTAG-NIC Wait, was that just a straight bash command? Is this installed on my computer? >$ whois usage: whois [-aAbdgiIlmQrR6] [-c country-code | -h hostname] [-p port] name ... Holy shit lol, that's neat.

> Wait, was that just a straight bash command? Is this installed on my computer? Welcome to 1982..1985. This command predates bash. https://tools.ietf.org/html/rfc812 http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/src/ucb...

[deleted]

Re: I mean, why not tell everyone our password hashes?

#93

Post by bogomipz »

problems wrote: post #56
bogomipz wrote: post #52

Earlier quoted context omitted.

?"The only bad thing about the GitHub issue there is that a de-anonymization attack is possible as an SSH server will tell you if it accepts a given public key" Could you elaborate more on this specific attack?

A quick overview of how SSH key authentication works: > SSH client: I support key auth > SSH server: Let's use key auth > SSH client: Do you take this public key hash: XXXXXX? > SSH server: Yes I do or > SSH server: No I don't Repeat for as many keys as you like. You can therefore grab a list of known public keys for a given person and ask a given ssh server if it knows about the given public key. Given a few days yo…

Sure, you would still need a Linux userid on that host (I'm assuming that PermitRootLogin is set to No.) Although that's probably easy to guess considering a person's name is often available in from Github or even the default comment field that ssh-keygen adds.

Re: I mean, why not tell everyone our password hashes?

#94

Post by throwaway76543 »

LeoPanthera wrote: post #88
nickh9000 wrote: post #64

Earlier quoted context omitted.

No, by all means share the MD5 hash of your passwords. After all it's a one way hash. /S

It's my understanding that even an MD5 hash of a not-terrible password is still virtually impossible to crack, is that wrong? Here's an md5 sum of a not-that-great password I just made up. It's 14 characters long, but has plenty of guessable features. Is it crackable? 1cf016ea3cb1f2aa2ccb59c196d0e704

Yes, that is incorrect. A GPU accelerated tool like HashCat can crack that password with a fairly small hardware footprint. Here's an article involving a 25 machine cluster which would reverse your hash in about 12 minutes -- regardless of your password features. http://www.zdnet.com/article/25-gpus-devour-password-hashes-...

This isn't nation-state level cost. Individuals could afford this level of hardware. Many individuals have access to systems of this size, for example through botnets, schools, spare junk in the local IT department closet, etc.

It's very reversible.

Re: I mean, why not tell everyone our password hashes?

#95

Post by yuhong »

dhimes wrote: post #40
developer2 wrote: post #18

One reason: you'd be surprised how many companies allow entering the hash as an alternative password to login to customers' accounts in production. Lazy method for customer support teams who don't have support tools to access customer information. Also frequently done to allow developers to debug problems on a customer's account when a bug cannot be reproduced elsewhere. If such a company's database of hashed passwor…

I....have no words. Effectively clear-text password storage. That should be criminal by now.

I wonder about using HMAC with a secret key that can be changed for things like this.

Re: I mean, why not tell everyone our password hashes?

#96

Post by CiPHPerCoder »

tedunangst wrote: post #48
CiPHPerCoder wrote: post #39

Earlier quoted context omitted.

Instead of password hashes, why don't we just use Argon2id as a KDF to produce an Ed25519 keypair, and then publish the (salt, memcost, opscost, Ed25519 public key)? I can throw this into a structure indistinguishable from a blockchain if any VCs want to invest ;)

Needs more FIPS to be enterprise ready.

Okay, let's throw in an invalid curve attack vulnerability and call it even. I'll contact NIST for a grant. Let's get this ball rolling!

Re: I mean, why not tell everyone our password hashes?

#97

Post by bogomipz »

dsacco wrote: post #67
bogomipz wrote: post #57

Earlier quoted context omitted.

I'm not familiar with this term "key stretching" is this the same thing as "work factor" in bcrypt/blowfish?

No, "work factor" is a term that (roughly) describes how computationally expensive brute-forcing the digest will be. They're associated terms, but it would be more accurate to think of the work factor as the final result of the key stretching process.

Ah I see, it's concerned with low entropy.

I believe this paper might be the origin of the term(correct me if I'm wrong.)

I thought it was a good read if anyone else is interested:

https://www.schneier.com/academic/paperfiles/paper-low-entro...

Re: I mean, why not tell everyone our password hashes?

#99

Post by seiferteric »

throwaway76543 wrote: post #94
LeoPanthera wrote: post #88

Earlier quoted context omitted.

It's my understanding that even an MD5 hash of a not-terrible password is still virtually impossible to crack, is that wrong? Here's an md5 sum of a not-that-great password I just made up. It's 14 characters long, but has plenty of guessable features. Is it crackable? 1cf016ea3cb1f2aa2ccb59c196d0e704

Yes, that is incorrect. A GPU accelerated tool like HashCat can crack that password with a fairly small hardware footprint. Here's an article involving a 25 machine cluster which would reverse your hash in about 12 minutes -- regardless of your password features. http://www.zdnet.com/article/25-gpus-devour-password-hashes-... This isn't nation-state level cost. Individuals could afford this level of hardware. Many in…

Don't forget spinning up an AWS cluster for 12 mins would not cost too much.

Re: I mean, why not tell everyone our password hashes?

#100

Post by Retric »

throwaway76543 wrote: post #94
LeoPanthera wrote: post #88

Earlier quoted context omitted.

It's my understanding that even an MD5 hash of a not-terrible password is still virtually impossible to crack, is that wrong? Here's an md5 sum of a not-that-great password I just made up. It's 14 characters long, but has plenty of guessable features. Is it crackable? 1cf016ea3cb1f2aa2ccb59c196d0e704

Yes, that is incorrect. A GPU accelerated tool like HashCat can crack that password with a fairly small hardware footprint. Here's an article involving a 25 machine cluster which would reverse your hash in about 12 minutes -- regardless of your password features. http://www.zdnet.com/article/25-gpus-devour-password-hashes-... This isn't nation-state level cost. Individuals could afford this level of hardware. Many in…

Uhh, 14 characters long.

Call it even ~30^14 / 348 billion per second = 1,374,416,379 seconds. So, they can break passwords with some pattern to them, but not really brute force em.

Post reply on HN