New 25 GPU Monster Devours Passwords In Seconds
securityledger.com
New 25 GPU Monster Devours Passwords In Seconds
1–10 of 91 posts
Re: New 25 GPU Monster Devours Passwords In Seconds
#2Exciting to see the technology behind this field progressing so quickly but troubling considering the passwords my users likely use. Though to be completely realistic their password hashes are very likely already known.
Re: New 25 GPU Monster Devours Passwords In Seconds
#3It looks like - contrary to the article - the presenters are discussing hash functions, not encryption[1]. There is a difference[2].
That said, I'd be curious to know how long it'd take a device like this to decrypt "secure" AES256 text.
Re: New 25 GPU Monster Devours Passwords In Seconds
#4I wonder what algorithm 1Password uses, and how it would fare, compared to the other options.
Re: New 25 GPU Monster Devours Passwords In Seconds
#5“I was extremely disappointed that setting up a clustered VMware instance wouldn’t allow me to create a VM that spanned all the hosts in the cluster. E.g. if i had five VMware ESX hosts with 8 processor cores, I wanted to be able to create a single vm with 40 cores and use all nodes in the cluster,” he wrote.
Not sure why he would have thought this would be possible. This would be an extremely hard problem given the latency involved between different nodes.
Then he came across VCL, or Virtual Open Cluster... “It did just what I wanted, not with an entire OS per se, but with an entire OpenCL application. and that’s good enough for me.”
A similar (but far older) system is MPI[1], which enables parallel computation across many compute nodes for your code by providing message passing. It's kind of a pain to use in my limited experience since you have to adapt your code (it seems like VCL is transparent for OpenCL programs), but it does work. No need for OpenCL, tho of course you could always use OpenCL + MPI. A common thing I see is MPI+OpenMP (for parallel cpu computation).
Re: New 25 GPU Monster Devours Passwords In Seconds
#6It looks like - contrary to the article - the presenters are discussing hash functions, not encryption[1]. There is a difference[2]. That said, I'd be curious to know how long it'd take a device like this to decrypt "secure" AES256 text. 1. https://hashcat.net/p12/js-sha1exp_169.pdf 2. http://stackoverflow.com/a/4948393
Passwords shouldn't be encrypted anyway. Chances are hackers will be able to obtain the key too, and then passwords are really easy to fetch.
Passwords should be hashed non-reversible (ideally using a slow hash). The original password is to no use of the application.
And sending plain-text passwords to users is even more bad[1].
Re: New 25 GPU Monster Devours Passwords In Seconds
#7I wonder what algorithm 1Password uses, and how it would fare, compared to the other options.
It encrypts all your passwords using AES with a 128 bit key derived from your master password (PBKDF2) [1].
This is very different to what the article is talking about, since it encrypts your passwords, but the article talks about hashing which is one-way.
[1] http://help.agilebits.com/1Password3/agile_keychain_design.h...
Re: New 25 GPU Monster Devours Passwords In Seconds
#8The numbers are ... misleading ... and choosing NTLM hashes seems like bordering on misinformation.
Taking SHA-1 (which YOU MUST NOT USE for password hashing blah), it manages 63 billion a second. To try all the passwords for that in the alphanumeric space:
- 10 chars: 35 weeks
- 11 chars: 44 years
- 12 chars: 2,800 years
- 16 chars: 11 times the age of the sun
10 chars for bcrypt: 600,000 years...
http://www.wolframalpha.com/input/?i=%2865**16+%2F+63+billio...
Re: New 25 GPU Monster Devours Passwords In Seconds
#9> VCL makes load balancing across the cluster – once an arduous task that required months of custom scripting – a trivial matter.
Surely this is an embarrassingly parallel problem that practically balances itself?
Re: New 25 GPU Monster Devours Passwords In Seconds
#10I wonder what algorithm 1Password uses, and how it would fare, compared to the other options.
It encrypts all your passwords using AES with a 128 bit key derived from your master password (PBKDF2) [1]. This is very different to what the article is talking about, since it encrypts your passwords, but the article talks about hashing which is one-way. [1] http://help.agilebits.com/1Password3/agile_keychain_design.h...
The problem with PBKDF2 however is that if you pick a weak password it's useless. It would be better if they included an option for a key as well like other password safes do.