
I mean, why not tell everyone our password hashes? - jorkro
https://theobsidiantower.com/2017/07/12/aef453e9f6c1a6125bcb97cc6a97ec2fde128574.html
======
jjguy
PSA to everyone responding to the title: please RTFA, it's sarcasm.

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

~~~
LeoPanthera
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

~~~
throwaway2016a
In reality while that would be really easy to crack (measured in minutes as
others pointed out).

However, any possible password with a standard printable ASCII character set
will typically be found in Rainbow tables up to 10 characters long making
expensive cracking unnecessary. [not quite right see edit]

Rainbow tables are just giant tables where the key is the hash and the value
is the string that generated it.

However, your example being 14 characters long is a bit long to be in most
readily available rainbow tables.

This is why using salts and peppers are incredibly important regardless of
what hash you use.

Edit: minor(ish) correction to the previous sentence. Full alphanumeric with
punctuation and digits is available readily in smaller password lengths but
the 10 character long datasets seem to be mostly only lower case characters
and digits.

~~~
visarga
If you know the md5 hash, why not login with another password that generates
the same hash value? Does it actually need to be the same passord?

~~~
throwaway2016a
It will work but a common reason to crack passwords is because people use the
same password on multiple sites. Getting the wrong value may work to log into
that specific site but will not work where the user the real password
elsewhere. (unless that other place is using the same hash algorithm)

------
developer2
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 passwords is leaked, then an attacker
doesn't even have to crack the hashes - the hash itself is a valid version of
the password. Yet I've seen this behavior at multiple companies; only one of
them pushed back against my request to remove that "feature", and I didn't
stay with them much longer after that.

~~~
cestith
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.

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

~~~
ams6110
Agree. MANY small development shops will build these kinds of backdoors into
systems because they don't have the skill or the resources to build proper
customer support features.

~~~
amenghra
Remember "Chuck Norris"...

------
lucasgonze
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.

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

~~~
tedunangst
Needs more FIPS to be enterprise ready.

~~~
CiPHPerCoder
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!

------
igonvalue
What exactly are these passwords used for? The post mentions "controlling this
object in the RIPE database" but I'm missing some context necessary to
understand that.

~~~
someone_elses
Basically you can take ownership of their IP ranges, modify routing
information, etc.

Even if you took a small percentage of the IP addresses in Europe, this could
have a snowball effect. You take the IP addresses belonging to a popular mail
service used by other domains, then you use admin email addresses to reset and
eventually Europes internet is stolen.

~~~
jbg_
It's not quite that simple. The RIPE database stores mostly administrative
information, and doesn't _directly_ affect Internet routing.

In order to "steal" IP addresses (get them routed to you) you would need to
buy a connection to at least one exchange point, probably several if you want
all the traffic for the target to route to you and not just some traffic from
some networks. You'd need to buy rackspace somewhere with a connection to the
exchange point, install routers, establish BGP peerings with the exchange
point (if they're doing route reflection) or with all the other major networks
at the exchange.

There are multiple steps along the way where humans would look at the prefixes
you were going to be announcing. This would include looking them up in RIPE,
but anything more than a cursory inspection would likely reveal your ruse.

At this point it becomes more of a social engineering attack, and even if you
got as far as announcing it, there are things like BGPMon that would pick up
the fraudulent announcement pretty quickly and you'd likely find that the
cable was pulled out of your router pretty fast.

~~~
someone_elses
Thank you!

------
zpallin
Shots fired.

That ending was an incredibly well delivered stab at Deutsche Telekom. This is
why I love vigilante security.

------
w8rbt
It depends on the hash type. Cryptographic hashes (MD4, SHA1, SHA256, etc.)
are made to be efficient and fast to compute while password hashes (bcrypt,
scrypt, etc.) are much more difficult to compute. The difference is
staggering.

    
    
      john --test --format=nt
    
      Benchmarking: NT [MD4 128/128 X2 SSE2-16]... DONE
    
      Raw:	29037K c/s real, 29037K c/s virtual
    
    
    
      john --test --format=bcrypt
    
      Will run 16 OpenMP threads
    
      Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/64 X3]... (16xOMP) DONE
    
      Raw:	5472 c/s real, 490 c/s virtual
    
    
    

___Edit: NT hashes are one round of MD4. These are Microsoft Active Directory
hashes. OpenBSD uses Blowfish hashes by default._ __

~~~
tobyjsullivan
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.

~~~
dsacco
_> 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 properties than regular hash functions. It's not like 3DES and
DES: a secure password hashing function requires more than just a higher
iteration count.

2\. "Key stretching" does not refer to running cryptographic hash functions
multiple times. Key stretching refers to the act of generating a secret key
from an otherwise weak passphrase or input, generally supplied by a user. You
use the user's passphrase to (in effect) seed a function that outputs
something much more resistant to brute-forcing. Key stretching is used in key
derivation functions, but what you described is not key stretching.

3\. General purpose (as opposed to password) hashing functions are designed to
be fast, not slow. Take a look at BLAKE2's homepage for speed comparisons -
speed is a selling point: [https://blake2.net/](https://blake2.net/). In
addition you can read the following from the handy FAQ:

 _You want your hash function to be fast if you are using it to compute the
secure hash of a large amount of data, such as in distributed filesystems
(e.g. Tahoe-LAFS), cloud storage systems (e.g. OpenStack Swift), intrusion
detection systems (e.g. Samhain), integrity-checking local filesystems (e.g.
ZFS), peer-to-peer file-sharing tools (e.g. BitTorrent), or version control
systems (e.g. git). You only want your hash function to be slow if you 're
using it to "stretch" user-supplied passwords, in which case see the next
question._

~~~
tobyjsullivan
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...](https://en.wikipedia.org/wiki/Cryptographic_hash_function#Password_verification)

~~~
snakeanus
> > 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.

This is not false, it is indeed one of the techniques that they use.

------
delegate
It's also nice enough to mention the hashing algorithm used - MD5, just so you
don't have waste time guessing.

------
pishpash
Passwords are broken for precisely this reason. You are operating under the
fiction that permanently handing over entropy from a limited source to an
untrusted party, even through a (for a time) one-way function, is ever a good
idea. Please do make all password hashes public. It will finally force the
move away from passwords.

------
ThePhysicist
Nice, they even have a rest API and web form to update the information:

[https://www.ripe.net/manage-ips-and-
asns/db/support/updating...](https://www.ripe.net/manage-ips-and-
asns/db/support/updating-the-ripe-database)

------
joshfraser
Stupid question, but what does this particular password hash unlock?

~~~
code_duck
I was wondering, too. From the article,

>"I hope like me you were immediately drawn to the ‘auth’ fields. As the name
implies this field contains authentication information for controlling this
object in the RIPE database. RIPE supports a couple of different auth types
like Single Sign On (SSO), public key cryptography, and of course md5."

It's authentication to manage that entry in the RIPE database.

------
jackjeff
It's hard to imagine worse, except maybe putting the passwords in the clear...

Single unsalted broken MD5 is a far cry from scrypt... and even scrypt is
probably a bad idea with all this crypto currency hashing hardware out there,
unless you have a seriously strong password.

Just don't publish hashes.

------
rdl
The PGP option has been the preferred option for as long as I can remember
(circa 2000).

------
royce
Threads discussing rainbow tables are not applicable.

These hashes are not unsalted MD5. They are md5crypt ($1$[salt]$[hash]), as
found in many Unix-likes and some Cisco IOS.

------
ewzimm
As you might have guessed, my password hash is password.

~~~
ademarre
Were this true, you would have achieved a pre-image attack.

~~~
yjftsjthsd-h
I like to think that if I ever gained the ability to execute preimage attacks,
solve P=NP, etc. I would use it to troll everyone by making my passwords hash
into "password", grabbing heylookicrackedpublickeyencryption.onion, and
emailing prominent security researchers messages signed with their own keys.

------
pmarreck
a simple unsalted hash wouldn't work due to rainbow-tabling, and even a salted
hash would be vulnerable to someone gaining unauthorized access to the salt
and regenerating a rainbow table with it (although if one used bcrypt, that
might be practically impossible)

~~~
mort96
There's not really such a thing as "gaining unauthorized access to the salt"
when you already have the hash; the salt is just as secret as the hash, and
the hash is useless as a means of authentication without the salt, so
obtaining the hash, unauthorized or not, generally also means you obtain the
salt. Libraries for algorithms like scrypt even usually give you one string
which contains both a random salt and a hash.

You can regenerate a rainbow table which uses that salt, but you'd have to
generate a rainbow table for every password, since each password has its own
random salt. I don't know how rainbow tables work exactly, but I'd assume an
old fashioned brute force attack or dictionary attack is cheaper than making a
rainbow table for each password.

------
cerved
ELI5

~~~
dentemple
TL;DR Don't tell people your passwords, even if they're "obscured" by a
hashing algorithm.

------
komali2
>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.

~~~
clarry
> 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](https://tools.ietf.org/html/rfc812)

[http://minnie.tuhs.org/cgi-
bin/utree.pl?file=2.11BSD/src/ucb...](http://minnie.tuhs.org/cgi-
bin/utree.pl?file=2.11BSD/src/ucb/whois.c)

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

~~~
ceejayoz
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".

~~~
Ajedi32
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.

~~~
ceejayoz
My password is not "tinkerbell". It serves as an example.

My real passwords look a lot more like the hash.

~~~
etrevino
Is your real password hunter2?

------
justin_vanw
Nah, why even give an inch? Yes, if you properly deal with passwords, the
artifact you store gives virtually no information to an attacker, but on the
other hand, why give them even almost nothing?

------
basseq
Sure, in an ideal world: post the hashes, the salts, the hash algorithm,
everything. If it's done "right" (e.g., the hash function has enough
complexity), then brute force cracking, rainbow tables, etc. would take so
long that it wouldn't be feasible to crack them with any volume.

Of course, you could still crack _some_ (problem), so keeping multiple secrets
hidden through obscurity (the hashes, the salts, etc.) is another layer of
security.

This doesn't guarantee _security_ , but it's certainly _more secure_. But it
is additive: there's no reason to just use MD5 (or plaintext) because "my
hashes are secret".

------
schoen
I was kind of disturbed that GitHub publishes every user's public key.

[https://developer.github.com/v3/users/keys/](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 there were specific key generation bugs, like RNG seeding errors,
people might actually be able to crack a few of them and know that they had
suceeded).

Relatedly, I was thinking about the magic crypto-cracking device in the movie
_Sneakers_. Once they had it, they could immediately use it to log on to
random network-connected services, defeating the authentication. So, how is
that supposed to work? How do they automatically know what credentials would
be accepted for a particular service? Are there common network authentication
protocols based on public-key cryptography that have the property that the
verifier tells the prover the public keys that it trusts?

~~~
LinuxBender
You can have a GitHub specific ssh key.

    
    
      ssh-keygen -q -t rsa -b 4096 -N "passphrase" -C "mygithub@someaddress.org" -f ${HOME}/.ssh/.ghub
    

then in your ${HOME}/.ssh/config

    
    
      IdentitiesOnly yes
      Host github.com
        Hostname ssh.github.com
        Port 443
        User git
        IdentityFile /home/username/.ssh/.ghub
        ForwardAgent no
    

Not that it matters in this case, just sayin'.

~~~
irundebian
2048 is enough.

~~~
snakeanus
For now.
[https://www.keylength.com/en/compare/](https://www.keylength.com/en/compare/)

Why risk it when generating an ed25519 or rsa4096 keypair is cheap?

~~~
irundebian
The same logic would apply to an 8192 bit key. One more bit doubles the key
space. Someone who is be able to crack 2048 bit keys, probably also has the
opportunity to crack 4096 bit keys. It may not be cheap for your communication
partners to use your 4096 bit key. Smartphones and embedded devices want to
use as less energy as possible. With an 4096 bit key, you force your
communication partners to spent an unnecessary amount of energy.

~~~
snakeanus
> One more bit doubles the key space

Yes, except that a 4096 bit key is not just "one more bit", it's double the
amount of bits.

> Someone who is be able to crack 2048 bit keys, probably also has the
> opportunity to crack 4096 bit keys

No, it would require an impossibly large amount of effort to crack 4096 bit
keys compared to 2048 bit keys.

> Smartphones and embedded devices want to use as less energy as possible

They can use ed25519 then.

> With an 4096 bit key, you force your communication partners to spent an
> unnecessary amount of energy.

They spend more energy by running ad-ridden "apps" and electron monstrosities.

