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

51–60 of 167 posts

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

#51

Post by LinuxBender »

schoen wrote: 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…

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

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

#52

Post by bogomipz »

problems wrote: post #45
schoen wrote: 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…

I wouldn't really say this is significant in an attack sense - you need to reveal your public key to engage in many types of secure communication, SSL throws these around all day as does any private messaging app, PGP, SSH servers, etc. The entire point of a public key is that it is public, password material on the other hand is not, it's meant to be a shared key between you and the other party. The only bad thing ab…

?"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?

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

#54

Post by problems »

etaty wrote: post #50
problems wrote: post #45

Earlier quoted context omitted.

I wouldn't really say this is significant in an attack sense - you need to reveal your public key to engage in many types of secure communication, SSL throws these around all day as does any private messaging app, PGP, SSH servers, etc. The entire point of a public key is that it is public, password material on the other hand is not, it's meant to be a shared key between you and the other party. The only bad thing ab…

If I remember, SSH server don't share the public key it accepts. Your SSH agent will try all your key one by one (you can change this behaviour with custom config)

Yes, but similarly if you have a given public key you can ask a server if it accepts that key with no need for the private key.

Basically, don't reuse keys in places where you might not want to be identified and use ssh configs to prevent announcing all keys to the world.

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

#56

Post by problems »

bogomipz wrote: post #52
problems wrote: post #45

Earlier quoted context omitted.

I wouldn't really say this is significant in an attack sense - you need to reveal your public key to engage in many types of secure communication, SSL throws these around all day as does any private messaging app, PGP, SSH servers, etc. The entire point of a public key is that it is public, password material on the other hand is not, it's meant to be a shared key between you and the other party. The only bad thing ab…

?"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 you could even scan the entire IPv4 space for servers taking a given public key. Username must match, etc of course, but it's an attack many people might not consider.

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

#57

Post by bogomipz »

dsacco wrote: post #43
tobyjsullivan wrote: post #28

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…

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

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

#58

Post by [deleted] »

bogomipz wrote: post #52
problems wrote: post #45

Earlier quoted context omitted.

I wouldn't really say this is significant in an attack sense - you need to reveal your public key to engage in many types of secure communication, SSL throws these around all day as does any private messaging app, PGP, SSH servers, etc. The entire point of a public key is that it is public, password material on the other hand is not, it's meant to be a shared key between you and the other party. The only bad thing ab…

?"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?

[deleted]

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

#59

Post by Terr_ »

recursive wrote: post #32
saulrh wrote: post #19

Earlier quoted context omitted.

That's what I thought when I read the title. There's probably some reason it wouldn't work. Dictionary attacks are an obvious possibility; if your password is "password" the only thing you're depending on is nobody being able to get at the hashes. It might also expose password reuse, though nonces/salts might solve that. Hrm. This smells a bit like public crypto - public database of public keys (hashes), on login you…

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

Wouldn't you want to use a salt instead?
Post reply on HN