I'm loosing trust on Firefox. There're already many criticism for Mozilla's attitude to security, not limited to years of lack of sandboxing, but see what CopperheadOS dev have been said on their site and Twitter. In this case, if you use strong password it's no problem. I always use pwd w/ 140+ bit of entropy for any important ones tho practically 120+ bit is enough. Note when your program use SHA1 for hashing, more than 160 bit password makes no sense. BTW the article uses quite vague word but actually LastPass or others do not use bare SHA1, but use PBKDF2-HMAC-SHA1 (or SHA256, 512, or other algorithm than PBKDF2) which shouldn't be confused.
About PBKDF2: Who decides the iteration count for that algorithm? For example, in WPA2 the PBKDF2 is used like this: Pre-Shared Key = PBKDF2(HMAC−SHA1, passphrase, ssid, 4096, 256) and the 4096 is the iteration count. In the 2000 the iteration count was 1000 and now 10 000 is recommended. But who decides it? The access point? The connecting client? Is it hardcoded (probably in old wifi routers?) or can be changed?
IDK about wifi AP, but for pwdmgr it depends on each program. LastPass & KeePass allow you to manually set iteration count if you don't like default. 1Password when you created 1Password account use 100,000 count PBKDF2-HMAC-SHA256, while dynamically adjust iteration count of PBKDF2-HMAC-SHA512 when you chose not to use 1Password account, depending machine power it runs on (minimum is 10,000 count). For more general question, it should be determined by machine power of common devices, but these days it ranges from powerless IoT device to highend work station so I think dynamic adjustment would be the best way, but new algorighms such as bcrypt, scrypt, Argon2 etc. require some parameters so it's harder to automatically determine good balance. It is often said PBKDF2 is out-of-date as it's not memory incentive thus weak to GPU or ASIC attack, but one of its successor, supposedly memory-hard scrypt was also 'broken' by optimized algorithm within several years after its debut (motivation behind this was Litecoin mining) so I think these new algorithms, including Argon2 are only a bit better than PBKDF2 and cautious ppl still have to use strong passwd, not rely much on these stretching.
Thanks Yuki I can't stopping thinking about wpa2, PBKDF2 and iteration count. So I did a lil experimenting and made a small C++ cmd-line program that creates the WPA2 PSK if password, ssid and iteration count are given. Run it 10 times for each iteration count 1000, 4096 and 10 000 and here are the results: 1000 iterations (wors 0.003451 seconds): 4096 iterations (worst 0.008422 seconds): 10 000 iterations (worst 0.013882 seconds): This with not particularly fast 2.5 GHz laptop. The difference between 1000 and 4096 is not that big but 10 000 starts to feel. Okay, let's say some bad guy has 10 million password dump list (available from net and even bigger ones too) and ditches all the passwords under and above 8 char length from that list (WPA2 passwords are between 8 - 63 ASCII) and keeps only password of exact 8 char length. And the bad guy would target old devices with iteration count 4096 or less. The salt for WPA2 is same as SSID (let's say it's "NETGEAR" and that is trivial to get by sniffing the airwave (maybe even if hidden?). It would take about 84220 seconds to generate 10 million WPA2 PSKs for that particular (NETGEAR) ssid. That's 23 hours. So under one day and attacker would have 10 million WPA2 keys for that particular SSID. And less if faster machine than mine (if anyone knows PBKDF2 generator Linux software or code for Nvidia CUDA then give a hint) All that now would be needed is capturing the WPA2 handshake and start comparing the captured PSK against that list. Here's quick online WPA2 PSK generator that I made: https://www.orwell1984.today/wpa2.php EDIT: Also the storage requirement for those 10 mil PSKs generated for 8 char passwords would not be that bad. The PSK is presented as 64 char hex string but the actual PSK key is half that, 32 bytes. So it would take around 305 MB for one table for that particular SSID. EDIT2: God I could store 41 255 different SSID tables each containing 10 million PSKs with one of those big hard drives that they sell out there (12 TB)
Nice experiment! It clearly shows how that 4,096 iteration count is far less than enough. Your PHP app works perfectly. I have read upcoming WPA3 is supposedly secure even when user set weak key, but IDK why it is. I'm waiting the details to be disclosed.
I have now optimized the cmd-line wpa2 generator little bit more ... Took few hours but I have now 1.5 million password+hash combos in 3 different tables (iteration count 1000, 4096 and 10 000) for one of common wifi router SSID and with 8 char long passwords as input. Total uncompressed size of tables 467 MB BTW, it's pretty insane that the firefox used iteration count of 1!
As these days we can buy GBs of storage & GPU of thousand cores cheaply (tho I know nothing about programming parallel processing), that should mean everyone can break wifi with weak passwd even when they changed a bit from default password, so probably WPA3 will improve this point much. Yeah, what's worrying is this has been ignored 9 years. It might reflect how much Mozilla and Firefox's open source contributor pay attention to its security...
You are right. It's very scary tought. Even in the case that the program that generates the cracking tables or program that lookup the correct hash from cracking tables had no multiprocessing support built-in, nothing prevents to run multiple instances of the same program with different datasets , minimizing the time to do table generation/lookup. Heh, if I had say, one of those sweet crazy AMD 32-core cpus, I could just start multiple instances of: ./wpa2 wordlist/p8.txt NETGEAR 4096 8 > tables/NETGEAR/p8_hashes.txt ./wpa2 wordlist/p9.txt NETGEAR 4096 9 > tables/NETGEAR/p9_hashes.txt and so on...each running on it's own terminal and cpu. Around half of the max 63 key length in one go And that's nothing if it would use GPU instead of CPU....****, I would need fast SSD to just keep up with the storing of tables (and this gives me an idea: several of those tables could with nicely into my laptop RAM...so why not create a RAM drive which is several times faster, even faster than SSD, for temporary storage and then just copy the ready tables to HD after done ... hmmmmm......) It's almost criminal negligence from their part. Just read the original specs for PBKDF2 from year 2000 https://www.ietf.org/rfc/rfc2898.txt and it says this: 4.2 Iteration Count An iteration count has traditionally served the purpose of increasing the cost of producing keys from a password, thereby also increasing the difficulty of attack. For the methods in this document, a minimum of 1000 iterations is recommended. This will increase the cost of exhaustive search for passwords significantly, without a noticeable impact in the cost of deriving individual keys. And if wikipedia is right then in wpa2 case, the iteration count is 4096 ... (we are so f%¤£&#!.... ) https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access It's like watching matrix ....
I didn't even know there's a 32 core CPU we can buy. (I'm not IT geek) From OP article, it sounds like Mozilla even didn't use PBKDF2, instead just a plain simple SHA1, tho not sure.
Here it is, 32-cores, 64 threads, but sadly meant for datacenters and maybe not available for consumers .... https://wccftech.com/amd-unveils-epyc-cpus-32-cores-64-threads-datacenter/ You are right, they used weaker PBKDF1 https://bugzilla.mozilla.org/show_bug.cgi?id=524403
