SSH Brute Force – The 10 Year Old Attack That Still Persists

Re:SSH Brute Force – The 10 Year Old Attack That Still Persists by andrewcooke on Monday July 15, 2013 @02:46PM (#6047699)

does that work when it's a system password that exists in a hashed (scrypt) database? it seems like it would leave things open to someone stealing the hashed system password.

if this can be made to work for ssh when using system passwords that would be very cool. but to my (inexpert) eye it seems unlikely (without relying on a trusted client). do you have a description for that case?

the problem, in short, is that the password is not shared. the server does not know it - it only knows the hash. and the hash is not sufficient as a shared secret.

[ Parent | on HN ]

Re:SSH Brute Force – The 10 Year Old Attack That Still Persists by shawnz on Monday July 15, 2013 @03:36PM (#6048043)

I'm not an expert, but your question has interested me for quite a while as well, so I did some research. It seems that SRP does not require the plaintext password to be stored by the server.

> SRP does not expose passwords to either passive or active network intruders, and it stores passwords as a "non-plaintext-equivalent" one-way hash on the server.

Source: http://srp.stanford.edu/analysis.html

[ Parent | on HN ]

Re:SSH Brute Force – The 10 Year Old Attack That Still Persists by andrewcooke on Monday July 15, 2013 @04:27PM (#6048356)

interesting, thanks. turns out there are even patches for ssh! http://srp.stanford.edu/links.html

but i get the impression that still doesn't mean that ssh can be made to work with system passwords without transmitting them (over an encrypted channel). i don't understand why - maybe srp requires a particular kind of hash?

ah yes - this answer http://security.stackexchange.com/questions/23821/srp-can-th... gives some details.

[ Parent | on HN ]