71–80 of 98 posts
> If you suspect against keyloggers or malware, Forgiva presents a visual confirmation ystem which leaves less hope for the attackers.
But maybe it's actually phishing?!?:
> And if you get registered, Forgiva uses your registration signature to generate special passwords for you. That means for a successful attack it will require keyboard and monitor access, plus a file system gain too.
> To crack a password with 70 bit entropy on a MacBook Pro Early 2013 it will take ~6 million years to complete all combinations on Normal complexity. On Intermediate complexity it will take ~24 million years and on Advanced complexity it will take ~280 million years to reach all combinations at minimum. If you were cracking a password wouldn't it be significantly faster to use GPU(s) rather than CPUs [1]? If so, why…
> If you were cracking a password wouldn't it be significantly faster to use GPU(s) rather than CPUs? When you're dealing with time scales greater than a decade, probably not. The right answer is almost always to wait until future hardware is available that can crack the password significantly faster than our current CPUs and GPUs. Whether that's quantum computers or just faster iterations of the kind of stuff we've…
Modern multi-GPU instances are 560,000x faster, 350 billion guesses per second. So that gets you to 6 million years / 560,000 = ~100 years. So "decade" isn't accurate in this case, but only because of the awful comparison to begin with. Comparing a 2013 CPU to even a 2013 GPU will give you a 100 or 1000x bump easily, and since this is a case of "embarrassingly parallel" operation your scale is much smaller than expected.
Also note: 350 billion is for NTLM in 2012. I can't find equivalent stats for modern GPUs from a few minutes of searching on my phone, but I know they're a factor of 2-10x better, so 2^70 is easily within reach.
> How about for sites with restrictive password requirements?
> Passwords, generated by Forgiva are offered with 16 characters minimum (you can go up to 32 characters by default) of length and 70 bits of entropy guaranteed on normal complexity level. And it is called on strong level for financial institutions and military grade applications.
> Thus it is not expected for any site to deny Forgiva generated passwords.
This seems naive, at best. If you can't store an eight character alphanumeric password, you're not usefully managing passwords.
Earlier quoted context omitted.
It would be better to use more hashing rounds as changing the algorithm itself doesn't require more computational effort from the attacker.
I argued with that since cryptographers first told me about it. Ludicrous concept. The goal is to eliminate brute force attacks by making the process inherently slow. That technique starts with something inherently ultra-fast that everyone is trying to speed up and hardware accelerate then iterates it a bit. Better concept to get a slow process is design an algorithm that is inherently slow and hard to speed up, esp…
Earlier quoted context omitted.
I argued with that since cryptographers first told me about it. Ludicrous concept. The goal is to eliminate brute force attacks by making the process inherently slow. That technique starts with something inherently ultra-fast that everyone is trying to speed up and hardware accelerate then iterates it a bit. Better concept to get a slow process is design an algorithm that is inherently slow and hard to speed up, esp…
Just pick a real password hash and dial up the hardness as high as you reasonably can for your environment. Don't do anything more complicated than that.
As I see it, the main benefit of deterministic password generation is the convenience of not needing a password database. Indeed, if the scheme is simple and/or portable enough (e.g., PBKDF2) you can implement it from scratch in a minute or two, depending on what software you have handy. The convenience breaks down as you need to maintain additional state: password rotation, site-specific password rules, etc. Forgiva…
>> Spamming the input with an array of whatever OpenSSL algorithms Ruby happens to make available, rather than using a memory hard KDF like scrypt, is a bad smell. Sooner or later key-derivation schemes gets outdated and requires a better version as happened to bcrypt [1] and will happen to scrypt [2]. It is not "whatever OpenSSL provides" but just combining strong algorithms over to spread the "getting outdated" ris…
I'm reading the open source code and this thing is... odd. For instance: it has a "simple", "intermediate", and "advanced" password complexity, and depending on which you choose, it uses SHA1, SHA2-256, and SHA2-512 for the PBKDF2 hash. What does password complexity have to do with the strength of the algorithm used to generate passwords? Also: it's 2016. Why is this using PBKDF2? If PBKDF2 is what you've got and you…
It is not the algorithm only but if you can look a little bit more closely, it is iteration count too. It uses 1.000 times and 10.000 times more iterations respectively.
Plus, depending on complexity, character set range enlarges.
>> Why is this using PBKDF2?
We would like to use more industry-standart way of things rather than individual works.
>> Is the "commercial" version of this also Ruby code wrapping OpenSSL?
Commercial version is purely written C version of it and backed up with OpenSSL on some cases.
Earlier quoted context omitted.
>> Spamming the input with an array of whatever OpenSSL algorithms Ruby happens to make available, rather than using a memory hard KDF like scrypt, is a bad smell. Sooner or later key-derivation schemes gets outdated and requires a better version as happened to bcrypt [1] and will happen to scrypt [2]. It is not "whatever OpenSSL provides" but just combining strong algorithms over to spread the "getting outdated" ris…
Not only did that not happen to bcrypt, but the whole point of bcrypt is that that doesn't happen: it's an adaptive hashing scheme, which means it comes with a dial you can turn to up the hardness as computers get faster. I would be nervous about taking password storage advice from someone who thinks bcrypt "got outdated and requires a better version". We had a Password Hashing Competition because people realized tha…
Sorry for misunderstanding.
I'm reading the open source code and this thing is... odd. For instance: it has a "simple", "intermediate", and "advanced" password complexity, and depending on which you choose, it uses SHA1, SHA2-256, and SHA2-512 for the PBKDF2 hash. What does password complexity have to do with the strength of the algorithm used to generate passwords? Also: it's 2016. Why is this using PBKDF2? If PBKDF2 is what you've got and you…
>> What does password complexity have to do with the strength of the algorithm used to generate passwords? It is not the algorithm only but if you can look a little bit more closely, it is iteration count too. It uses 1.000 times and 10.000 times more iterations respectively. Plus, depending on complexity, character set range enlarges. >> Why is this using PBKDF2? We would like to use more industry-standart way of th…
Why do simpler passwords get a different construction? What does password complexity have to do with KDF hardness?
Earlier quoted context omitted.
>> Spamming the input with an array of whatever OpenSSL algorithms Ruby happens to make available, rather than using a memory hard KDF like scrypt, is a bad smell. Sooner or later key-derivation schemes gets outdated and requires a better version as happened to bcrypt [1] and will happen to scrypt [2]. It is not "whatever OpenSSL provides" but just combining strong algorithms over to spread the "getting outdated" ris…
What evidence do you have that your scheme is any more future proof than, say, Argon2? No, just using a bunch of different primitives is not going to guard against the kind of breaks found in bcrypt or scrypt, which aren't really breaks at all.
And in this case which methods would you offer and prefer for future-proofing with comparison to other KDFs?