Only if permutations are unknown - which is not the case with open source software forms like CBoardOriginally Posted by Sebastiani
Only if permutations are unknown - which is not the case with open source software forms like CBoard
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
What password managers do yall use? Brain, notepad, etc...
gg
It doesn't matter that the attacker knows the permutation policy; this isn't security-by-obscurity. Suppose the attacker has somehow obtained a list of your database's usernames and hashes. In an "off-line attack", he now just has to find some password that produces a hash on the list. Without permutation constraints, he might find that the sequence, say "afgetdk3k", that just happens to hash to the same value as one of the user's, who's real password (not known to the attacker) is "foobarbaz", the attacker can nonetheless login because the hashes match. If instead you apply something like the "reverse permutation" constraint to your policy it becomes much harder for the attacker to find a password that produces a hash identical to one of the users while fulfilling the constraint.
Last edited by Sebastiani; 10-10-2013 at 10:43 AM.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Brain. Which of course means I get a lot of password resets via email.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Hmm, now that I think about it, it would still be a good idea to use "normal salts" in addition to this scheme to prevent the mounting of effective dictionary-based attacks.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
It sounds like all you are doing is extending the hash algorithm by prepending one or more steps to permute the password. Since you say the attacker is permitted to know how you extended the algorithm as it is not security by obscurity, it seems to me that the added security is akin to adding one or more rounds of key stretching, so it would not really be better than using a salt known to the attacker when applying key stretching.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
O_oIf instead you apply something like the "reverse permutation" constraint to your policy it becomes much harder for the attacker to find a password that produces a hash identical to one of the users while fulfilling the constraint.
The approach you are describing, if publicly known, doesn't actually become "much harder" to attack.
As is known with such systems, the security is as strong as the strongest security of any required step.Code:[username][salt][password-hash][permutation-hash]
The attack doesn't need to consider `password-hash' at all.
If you find `permutation-hash', you already know `password-hash' by definition. Your attackers are not going to find `password-hash' to be kind; they are going to skip that step because it is irrelevant. Your attackers are simply going to attack `permutation-hash'.
What you suggest is a trivial change to existing algorithms: compute the permutation before hashing.
The cost of hashing, against a good repeating block, is the cost of an attack. The cost of the attack isn't simply the cost of hashing the password; the real difficulty comes from the number of repetitions in the hashing block. By comparison, the cost of reversing and duplicating the context of each attempt is trivial. (The cost is linear with the length of the context, but each thread has its own context so this isn't a significant reduction.) The only change, with your proposal, comes in that the cost of each hash is determined over the length of the context (In other words, it simply takes a little more time to hash a longer password.). However, the associated entropy of the real password hasn't been doubled.
You haven't actually increased the difficulty of the attack at all: you've falsely increased the required password length without significantly changing the entropy of the passwords themselves.
That said, your proposal has a different cost I would not pay. With a good security implementation, the cost of hashing is already configurable, "online" in many cases, by changing the number of repetitions of the hashing block. Your proposal changes the implementation, slightly, without a meaningful change in the difficulty of an attack, but for the sake of argument, let us assume that doubling the password in this way doubles the difficulty of the attack. With common security packages, I can change one value in the configuration and meaningfully double the cost of an "offline attack". A significant difference between "what is" and your proposal: I can continue to increase the associated configuration value as "compute" becomes cheaper thus increasing the difficulty of an attack without changing the implementation or migrating data.
Soma
“Salem Was Wrong!” -- Pedant Necromancer
“Four isn't random!” -- Gibbering Mouther
Yeah, good points both.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Roboform
Still, the purpose of a sale is to increase the time it takes to compute a password, which means it would take longer for someone to brute-force crack the password, so adding a reversed password or some such might not be a bad idea. We do commonly use salt for exactly this reason.
Salt increases cracking time a little bit, but the more important purpose of salt is to prevent dictionary attacks. A dictionary generated using one specific salt (or no salt) is useless against another salt. So if each user has a different salt there is no single dictionary that can work for all of them.
It doesn't inherently increase the effort of brute force cracking, however, as you will eventually find some password that works no matter what the salt is or how it is salted. Again, this is because of the fixed length of the hash output.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
O_oStill, the purpose of a sale is to increase the time it takes to compute a password, which means it would take longer for someone to brute-force crack the password, so adding a reversed password or some such might not be a bad idea. We do commonly use salt for exactly this reason.
That is not why we use a salt.
A salt doesn't meaningfully change the cost of hashing a password.
A salt changes the attack surface.
With classic "rainbow tables" and "dictionary attacks", here forming an "offline" assault against a dumb table, the attacker only needs to find a collision where any collision will do the job.
By using a salt, you demand a level of specificity. Your attackers, again forming an "offline" assault, don't get to use as much statistical methods and large scoping to attack any account that may be worthwhile.
The salt, very effectively, reduces the utility of those classic attack patterns because each user requires a unique pass through the hash block.
Soma
“Salem Was Wrong!” -- Pedant Necromancer
“Four isn't random!” -- Gibbering Mouther
I use passwords like "rockmate", "pepperspray" "anathol" and "badpassword". It's just that at some point I gave up on everything.
I tend to have a group of supposedly highly secure computer generated passwords for special places in the net, like my MSDN and Google accounts. But the fear of loosing all these impossible to memorize passwords to a computer accident and the constant need to manage and keep an healthy backup of these passwords in some file that needs to be itself secured by a memorizable password just seems... like the world has gone nuts and I'm one of the nuts.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Security does really start at home. I used to use bad passwords and never really had a problem because I kept them a secret. If they're stored elsewhere insecurely, what can I really do about that.
I gave up and started using managers because I didn't want to waste brain space on passwords. I guess when discussing what's convenient, it can end up going in either direction.
