Like Tree10Likes

The End of the Age of the Password

This is a discussion on The End of the Age of the Password within the General Discussions forums, part of the Community Boards category; Originally Posted by Sebastiani The more "permutation constraints" imposed on the input, the better the security... Only if permutations are ...

  1. #16
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    Quote Originally Posted by Sebastiani View Post
    The more "permutation constraints" imposed on the input, the better the security...
    Only if permutations are unknown - which is not the case with open source software forms like CBoard
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  2. #17
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,671
    What password managers do yall use? Brain, notepad, etc...

    gg

  3. #18
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Quote Originally Posted by vart View Post
    Only if permutations are unknown - which is not the case with open source software forms like CBoard
    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;
    }

  4. #19
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Quote Originally Posted by Codeplug View Post
    What password managers do yall use? Brain, notepad, etc...

    gg
    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;
    }

  5. #20
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    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;
    }

  6. #21
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,746
    Quote Originally Posted by Sebastiani
    One way to strengthen collision-resistance would be to replace the publicly-known salt with one or more permutations of the password itself. So for instance, suppose the password is "foobarbaz". Append the reverse to obtain "foobarbazzabraboof" and then compute the hash. Now the attacker is forced to find a password that when concatenated it's reverse produces the correct hash, a much harder problem. The more "permutation constraints" imposed on the input, the better the security...
    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.
    Sebastiani likes this.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  7. #22
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,261
    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.
    O_o

    The approach you are describing, if publicly known, doesn't actually become "much harder" to attack.

    Code:
    [username][salt][password-hash][permutation-hash]
    As is known with such systems, the security is as strong as the strongest security of any required step.

    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
    Sebastiani likes this.
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  8. #23
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    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;
    }

  9. #24
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,620
    Quote Originally Posted by Codeplug View Post
    What password managers do yall use? Brain, notepad, etc...

    gg
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #25
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by Elysia View Post
    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);
    //}

  11. #26
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,261
    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.
    O_o

    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
    laserlight likes this.
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  12. #27
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,470
    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.
    Elkvis likes this.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  13. #28
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,707
    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.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 01-07-2009, 09:35 AM
  2. password box in c#
    By deviousdexter in forum C# Programming
    Replies: 2
    Last Post: 12-12-2008, 04:45 PM
  3. Password help
    By alexnb185 in forum C Programming
    Replies: 16
    Last Post: 08-10-2007, 05:31 PM
  4. Password help
    By Necrofear in forum C++ Programming
    Replies: 11
    Last Post: 01-05-2005, 08:03 PM
  5. password
    By Unregistered in forum A Brief History of Cprogramming.com
    Replies: 17
    Last Post: 03-15-2002, 01:38 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21