Live data from Hacker News

I mean, why not tell everyone our password hashes?

theobsidiantower.com

71–80 of 167 posts

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

#71
post #41

I was kind of disturbed that GitHub publishes every user's public key. https://developer.github.com/v3/users/keys/ This is a different situation and public keys are not directly analogous to password hashes: there isn't a reliable way of cracking public keys in the same sense that there's a semi-reliable way of cracking hashes. But it was still strange and uncomfortable to me that they would reveal this "target" (and…

If you prefer plain-text format, this is available at:

  https://github.com/.keys

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

#72

That inspired this idea: make all password databases public, in an encrypted form. Just post them in a standard location. This is to get rid of the fiction that these are ever private and to eliminate an incentive to break in.

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

As long as you call it a blockchain, I'm in!

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

#73
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...

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

#74
post #59

Earlier quoted context omitted.

If you're using a keyed hash, then dictionary attacks can't be parallelized.

Wouldn't you want to use a salt instead?

You use the 'salt' as the key in the keyed hash.

The difference occurs mostly when you start chaining hashes. In that case, a salt is only relevant in the first hash, whereas the keyed hash needs the key at every hash round.

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

#75
post #36

Earlier quoted context omitted.

If your password is "tinkerbell", even an attacker with very few resources can probably crack the hash for it in seconds on their desktop PC.

My password is not "tinkerbell". It serves as an example. My real passwords look a lot more like the hash.

Is your real password hunter2?

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

#76

Earlier quoted context omitted.

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

Even SHA512 and bcrypt, totally uncrackable! /S

Every time someone says or writes "bcrypt", the GPU prices go up $10.

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

#77

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…

Expanding this to the tor case that the GGP outlined, even if the server isn't compromised the use of the same key in two very different contexts (for git and for your silkroad command console) reveals that the client is one and the same. I believe just packet sniffing can ascertain this.

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

#78

Because your password is part of your identity and is actually used to cross check during identity matching.

Leaving aside the fact that changing my password doesn't mean I have a new identity, having the hash $2y$10$/Aglzm2zpHO7m1dIv5vSp.GHPUd1D8uODn/jtBv3gpe8yS5e/D9PW doesn't tell you my password is "tinkerbell".

In these kind of checks nobody cares what your password is. Only if it is the same as you are using somewhere else.

So hash, unless properly salted, works works very fine.

Many people actually use a single password everywhere. Or at least for similar things.

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

#79
post #43

Earlier quoted context omitted.

Password "hashes" are generally just cryptographic hashes run multiple times (known as key stretching). Cryptographic hashes are also designed to be slow. A key stretching algorithm will only be slow if the underlying cryptographic hashes are sufficiently slow.

> Password "hashes" are generally just cryptographic hashes run multiple times (known as key stretching) 1. Password hashing functions are not regular hash functions run multiple times. This is not only false at a macro level (i.e. we don't just run SHA-2 several times to get something resembling PBKDF2), it's false in terms of core construction. Password hashing functions rely on fundamentally different mathematical…

Well that was embarrassing. Thanks for the corrections!

There's a Wikipedia line that could use your input (unless I'm missing why this would still be accurate).

> Key stretching functions, such as PBKDF2, Bcrypt or Scrypt, typically use repeated invocations of a cryptographic hash to increase the time required to perform brute force attacks on stored password digests.

https://en.wikipedia.org/wiki/Cryptographic_hash_function#Pa...

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

#80

That inspired this idea: make all password databases public, in an encrypted form. Just post them in a standard location. This is to get rid of the fiction that these are ever private and to eliminate an incentive to break in.

The foundation of modern ecommerce rests on the belief that your credit card information won't be stolen and used to cause great harm. Similar belief systems exist for online dating, social media, etc.

[deleted]
Post reply on HN