Your password is too good



  • From apc.com:

    Wait, what?



  • The if-statement is missing:

    "[b]if x[/b] then password should not exceed 12 characters"



  • Yawn, been there, done that.



  •  That is a bad sign. That probably means that the password is stored in plaintext, and not hashed as it should be.



  • @AnonDev said:

     That is a bad sign. That probably means that the password is stored in plaintext, and not hashed as it should be.


    No, I've seen a few programs with an upper limit for the password store as a hash. Windows and SocketMUD come to mind immediately.



  • @Lingerance said:

    @AnonDev said:

     That is a bad sign. That probably means that the password is stored in plaintext, and not hashed as it should be.

    No, I've seen a few programs with an upper limit for the password store as a hash. Windows and SocketMUD come to mind immediately.

    Plenty do.  crypt is limited to 8 bytes.  bcrypt is limited to 55 bytes.



  • How exactly are symmetric ciphers like DES or Blowfish used as one-way hash functions, anyway?



  • @snover said:

    How exactly are symmetric ciphers like DES or Blowfish used as one-way hash functions, anyway?

    IIRC, the password is coerced into a key and then used to encrypt a known plaintext several times over.   Since the password is used as a key, its length is limited to the length of a key for that cipher.



  • @snover said:

    How exactly are symmetric ciphers like DES or Blowfish used as one-way hash functions, anyway?
    I was going to say it was based on the honour system, but what morbius said makes sense too.



  • If someone does that, they should lose their rights to write security code.  If you DES encrypt something once, you get 56 bits of strength.  If you DES encrypt it again (with a different key), you get 57 bits of strength.  Triple DES is 112 bit effective strength.

    There are also plenty of algorithms to coerce an arbitrary length password into an arbitrary length key.



  • @Jaime said:

    If someone does that, they should lose their rights to write security code.  If you DES encrypt something once, you get 56 bits of strength.  If you DES encrypt it again (with a different key), you get 57 bits of strength.  Triple DES is 112 bit effective strength.

    I have a feeling you don't know what the fuck you're talking about.  crypt has been around forever.  It's not secure today because DES is too easy to brute-force.  bcrypt works the same way, although it uses blowfish with an expensive key schedule and is thus far more difficult to brute force.  bcrypt is one of the most secure password "hashing" schemes in existence.

     

    @Jaime said:

    There are also plenty of algorithms to coerce an arbitrary length password into an arbitrary length key.

    Of course, but it gains you no security.  In fact, it probably costs you.  The key length is a set size.  You can take a password that is too long and reduce it but 1) it gives the user a false sense of security because beyond a certain length the password isn't any stronger and 2) the algorithm that does the reduction might very well introduce patterns in the generated key reducing the keyspace greatly.  The only safe way is to set a maximum length and pad the password if it is shorter than the maximum.



  • @morbiuswilters said:

    @Jaime said:

    If someone does that, they should lose their rights to write security code.  If you DES encrypt something once, you get 56 bits of strength.  If you DES encrypt it again (with a different key), you get 57 bits of strength.  Triple DES is 112 bit effective strength.

    I have a feeling you don't know what the fuck you're talking about.  crypt has been around forever.  It's not secure today because DES is too easy to brute-force.  bcrypt works the same way, although it uses blowfish with an expensive key schedule and is thus far more difficult to brute force.  bcrypt is one of the most secure password "hashing" schemes in existence.

     

    @Jaime said:

    There are also plenty of algorithms to coerce an arbitrary length password into an arbitrary length key.

    Of course, but it gains you no security.  In fact, it probably costs you.  The key length is a set size.  You can take a password that is too long and reduce it but 1) it gives the user a false sense of security because beyond a certain length the password isn't any stronger and 2) the algorithm that does the reduction might very well introduce patterns in the generated key reducing the keyspace greatly.  The only safe way is to set a maximum length and pad the password if it is shorter than the maximum.

    Really, the bcrypt technique is better for hashing than SHA512?  I'd like to see something published from a security specialist stating that.  The general rule of crytography for mortals is "Never use any cryptographic technology for anything other than its designated purpose, and never implement it yourself."

    Standard .Net setup of an AES encrytor/decryptor:

    string password = "passwordofanylengthwillworkhere";
    RijndaelManaged alg = new RijndaelManaged();
    byte[] salt = Encoding.ASCII.GetBytes("salttomakerainbowtableslesseffective");
    Rfc2898DeriveByes key = new Rfc2898DeriveBytes(password, salt);
    alg.Key = key.GetBytes(alg.KeySize / 8);
    alg.IV = key.GetBytes(alg.BlockSize / 8);

    Please read RFC2898 for standard key derivation algorithms.



  • @Jaime said:

    Really, the bcrypt technique is better for hashing than SHA512?

    Yes.  Message digest algorithms are considered to always have cryptographic weakness.  What's more, SHA512 is very quick to run, whereas bcrypt chews a lot of CPU.

     

    @Jaime said:

    I'd like to see something published from a security specialist stating that.

    Then Google it, you lazy fuck.

     

    @Jaime said:

    The general rule of crytography for mortals is "Never use any cryptographic technology for anything other than its designated purpose, and never implement it yourself."

    Right.  And bcrypt was created for being the most secure password hashing algo around.  Why is that so hard for you to understand?



  • @morbiuswilters said:

    @Jaime said:

    Really, the bcrypt technique is better for hashing than SHA512?

    Yes.  Message digest algorithms are considered to always have cryptographic weakness.  What's more, SHA512 is very quick to run, whereas bcrypt chews a lot of CPU.

     

    @Jaime said:

    I'd like to see something published from a security specialist stating that.

    Then Google it, you lazy fuck.

     

    @Jaime said:

    The general rule of crytography for mortals is "Never use any cryptographic technology for anything other than its designated purpose, and never implement it yourself."

    Right.  And bcrypt was created for being the most secure password hashing algo around.  Why is that so hard for you to understand?

    I Googled it.  This is the first paragraph at http://bcrypt.sourceforge.net/

    Description

    Bcrypt is a cross platform file encryption utility. Encrypted files are portable across all supported operating systems and processors. Passphrases must be between 8 and 56 characters and are hashed internally to a 448 bit key. However, all characters supplied are significant. The stronger your pass phrase, the more secure your data.

    bcrypt it an encryption tool, not a hashing tool.



  • I did some more research and it seems that the hash portion of the bcrypt encryption tool is sometimes exposed in libraries.  This is different from Blowfish encrypting the password.  I couldn't find the implementation details, but I'll bet it's similar to RFC 2898.  When people do actually Blowfish encrypt the password, it isn't to make it more cryptographically secure, but to increase the time it takes to brute force by using a slower algorithm.  Since anything over 128 bits is never going to be brute forced anyways, this is actually irrelevant.  If Blowfish is ever found to be weak, doing it several times isn't going to help.  The DES example I provided above was an actual example of an algorithm that, at the time of its acceptance, didn't have any known attacks.  However, it was later found the two rounds of DES was pointless.



  • @Jaime said:

    Since anything over 128 bits is never going to be brute forced anyways, this is actually irrelevant.
    That is a pretty naïve way of looking at it. People used to say that about DES.

    @Jaime said:

    If Blowfish is ever found to be weak, doing it several times isn't going to help.
    That depends upon the sort of cryptanalysis that the algorithm is weak against. In any case, crypting over multiple rounds is designed to increase the amount of time it takes to do a brute-force key search, nothing more.



  • @snover said:

    @Jaime said:

    Since anything over 128 bits is never going to be brute forced anyways, this is actually irrelevant.
    That is a pretty naïve way of looking at it. People used to say that about DES.

    At 128 bits, it would take all of the available entropy in the galaxy to power the computer that does it.  This is assuming the most efficient computer that can be built using the physical principals that computers work under today.



  • @snover said:

    @Jaime said:

    If Blowfish is ever found to be weak, doing it several times isn't going to help.
    That depends upon the sort of cryptanalysis that the algorithm is weak against. In any case, crypting over multiple rounds is designed to increase the amount of time it takes to do a brute-force key search, nothing more.

    Good thing you already know what it will be weak against so you can make the decision for me as to whether multiple rounds introducing a weakness is a bigger problem than protecting against brute forcing the key.  Both of these are out of the realm of possibility today.  I am arguing that is is more likely that Blowfish has a weakness similar to DES (see above) than quantum computing being perfected.



  • @morbiuswilters said:

    I have a feeling you don't know what the fuck you're talking about.

    @morbiuswilters said:

    Then Google it, you lazy fuck.

    @morbiuswilters said:

    Why is that so hard for you to understand?

    Look at my handful of posts on this site.  Almost all are useful answers to difficult questions.  I am seriously considering making it my hobby to find any opportunity to make your life more difficult.

    Here is my reasoning why the "encrypt the password a bunch of times with Blowfish to generate an encryption key" technique isn't a good idea for the problem presented in the original post:

    1.  Using encryption instead of hashing destroys nonrepudiation.  However, you did say that you would store a known plaintext encrypted with the derived key, so that would restore nonrepudiation.  You shouldn't need to go through this many hoops for reasonable security.  I wonder if it has any other flaws that haven't been considered?

    2.  The decision that Blowfish would be a good idea was based on best practices instead of a threat analysis.  It turns out that this technique isn't useful against a brute-force attack since it is computationally impossible to break any modern enryption by brute force.  However, the technique does help against dictionary attacks.  If this were a workstation based application, then a dictionary attack would be a real concern.  A compression tool that supports encryption would benefit greatly from this technique because it would prevent offline dictionary attacks.  But, this is a web based authentication system.  Dictionary attacks are much easier to spot on web sites.  Solving the problem with your solution turns break-ins into DOSes.  That is why it is not a good solution -- it pushes the processor cost onto the web server, not the attacker.

    3.  The solution to the nonrepudiation problem from #1 causes a new problem.  Since there is a one to one correlation between the key that was the output of the multi-round Blowfish process and the ciphertext stored as the authentication key, this is now vulnerable to rainbow table attacks.  The more traditional per-record unique salt used along with a good hash algorithm is rainbow table proof.

    4.  You also mentioned that hash algorithms have cryptographic weaknesses.  I cannot disagree.  However, this is already accounted for.  Just like PKCS isn't secure under 4096 bits due to cryptographic weaknesses, SHA512 still has plenty of strength even after accounting for the history of hash algorithm weaknesses that have shown up in the past.  MD5 is broken, but only totally broken in the chosen-plaintext scenario.  It still has 60 or so bits of security left if someone uses every known shortcut that exploits its flaws in the non-chosen-plaintext scenario.  The infamous RapidSSL MD5 fake SSL certificate was actually created using a limited chosen-plaintext attack and it took about 2^51 brute force attempts.  SHA-1 (a 160 bit algorithm) is down to 63 bits effective security, but it is old.  SHA512 is projected to have plenty of life left and NIST is already working on selecting an algorithm for the SHA-3 family.  Skein would be a good choice to jump on this bandwagon early.

    It may turn out that I am not on the right side in this discussion.  But, if I am wrong, it will be because of some trade-off that I didn't consider and will have some degree of subjectivity.  I am not a drooling moron and I am not out of my element in this discussion.  I will continue to discuss it rationally if anybody wants to.



  •  @Jaime said:

     I will continue to discuss it rationally if anybody wants to.

    We only discuss WTF's in "Side Bar" WTF. Actually, I think I see one coming soon...



  • @Jaime said:

    At 128 bits, it would take all of the available entropy in the galaxy to power the computer that does it.  This is assuming the most efficient computer that can be built using the physical principals that computers work under today.

    WTF. You know that there are computers that are effectively 128 bit right? Guess what the're commonly used for. Generally one doesn't tryo to break encryption with a single computer, but instead uses a cluster of them working a parallel, using 128-bit encryption for anything now-a-days is absurd. You also appear to be assuming the breaking computer has to reach ~0 (bit-wise not), it doesn't, it only needs to reach the key.



  • @Lingerance said:

    @Jaime said:
    At 128 bits, it would take all of the available entropy in the galaxy to power the computer that does it.  This is assuming the most efficient computer that can be built using the physical principals that computers work under today.
    WTF. You know that there are computers that _are_ effectively 128 bit right? Guess what the're commonly used for. Generally one doesn't tryo to break encryption with a single computer, but instead uses a cluster of them working a parallel, using 128-bit encryption for anything now-a-days is absurd. You also appear to be assuming the breaking computer has to reach ~0 (bit-wise not), it doesn't, it only needs to reach the key.

    From the wikipedia page on brute force (http://en.wikipedia.org/wiki/Brute_force_attack)

    There is a physical argument that a 128-bit symmetric key is secure against brute force attack. The so-called Von Neumann-Landauer Limit implied by the laws of physics sets a lower limit on the energy required to perform a computation of ln(2)kT per bit erased in a computation, where T is the temperature of the computing device in kelvins, k is the Boltzmann constant, and the natural logarithm of 2 is about 0.693. No irreversible computing device can use less energy than this, even in principle.<FONT size=2>[1]</FONT>

    Thus, in order to simply flip through the possible values for a 128-bit symmetric key (ignoring doing the actual computing to check it) would require 2<FONT size=2>128</FONT> − 1 bit flips. If we assume that the calculation occurs near room temperature (~300 K) we can apply the Von Neumann-Landauer Limit to estimate the energy required as ~10<FONT size=2>18</FONT> joules, which is equivalent to consuming 30 gigawatts of power for one year (30×10<FONT size=2>9</FONT> W×365×24×3600 s = 9.46×10<FONT size=2>17</FONT> J). The full actual computation—checking each key to see if you have found a solution—would consume many times this amount.

    Also from http://en.wikipedia.org/wiki/Large_numbers#Computers_and_computational_complexity:

    Such limits are an advantage in cryptography, since any cipher-breaking technique which requires more than, say, the 10<FONT size=2>120</FONT> operations mentioned before will never be feasible. Such ciphers must be broken by finding efficient techniques unknown to the cipher's designer.



  • @Lingerance said:

    You also appear to be assuming the breaking computer has to reach ~0 (bit-wise not), it doesn't, it only needs to reach the key.
    So it only has to test 170,141,183,460,469,231,731,687,303,715,884,105,728 possible keys (on average) instead of 340,282,366,920,938,463,463,374,607,431,768,211,456. What's a factor of two between friends?




  • @Jaime said:

    Look at my handful of posts on this site.  Almost all are useful answers to difficult questions. 
     

    UR DOIN IT RONG



  • @Jaime said:

    1.  Using encryption instead of hashing destroys nonrepudiation.  However, you did say that you would store a known plaintext encrypted with the derived key, so that would restore nonrepudiation.  You shouldn't need to go through this many hoops for reasonable security.  I wonder if it has any other flaws that haven't been considered?
    It is, at its root, the same system that has been used by *nix and BSD crypt(3) for decades, only with more secure algorithms and variable rounds. I would be very very surprised if you were discovering flaws that nobody else has considered.

    @Jaime said:

    If this were a workstation based application, then a dictionary attack would be a real concern.  But, this is a web based authentication system.  Dictionary attacks are much easier to spot on web sites.  Solving the problem with your solution turns break-ins into DOSes.  That is why it is not a good solution -- it pushes the processor cost onto the web server, not the attacker.
    This is true. However, you are missing part of the picture. A single SQL injection vulnerability or unprotected database dump can provide an attacker with the entire user table, allowing them to set up a bunch of AWS instances and throw lots of compute time at the problem. As such, the additional expense is still highly valuable. To mitigate the undesired problem of expensive password calculation, the server can be configured to block login attempts after a certain number of failures, thus limiting the amount of damage that can be done by brute-force attempts against the server itself. In addition, bcrypt allows you to adjust the cost depending upon how computationally intensive you want bcrypt to be, so if you decide that it’s too slow, you can reduce it. (Or if you decide it’s too fast, you can increase it. By default, it uses 2^8 rounds.)

    @Jaime said:

    3.  The solution to the nonrepudiation problem from #1 causes a new problem.  Since there is a one to one correlation between the key that was the output of the multi-round Blowfish process and the ciphertext stored as the authentication key, this is now vulnerable to rainbow table attacks.  The more traditional per-record unique salt used along with a good hash algorithm is rainbow table proof.
    A salt is calculated and used as part of the hashing process. Nobody qualified would be stupid enough to design a password hashing system that didn’t use salt.

    Here is the bcrypt algorithm description, for your reference, since it sounds like you maybe didn’t read it.



  • @snover said:

    ...stuff...

    Since all you did was repeat back to me that the only advantage of the bcrypt technique was that it is computationally expensive, I'm not sure why you bothered to go into all that description or to quote a reference that once again states what you and I had already bounced back and forth previously in this thread -- the fact that this technique is computationally expensive.  It is also unclear to me why you think I wouldn't know the content of that article and already agree with every word of it.  However, instead of discussing the actual issue, whether adding computational expense on server side code is an overall benefit or detriment, you simply left that as assumed and added "well if you are have a SQL injection vulnerability, then it can be escalated into a password attack".  A SQL injection vulnerability is already worse than a password attack, it allows data modification and possibly privilege escalation.  That's like locking your fridge so the guy that breaks into your house won't eat your food.

    Ley me say this unequivocally so that we don't need to hash it out again -- I agree that it is important to make it computationally expensive to mount a dictionary attack on a client-installed system.  Unfortunately, we are not discussing a client-installed system on this thread.

    My main position is that a full threat analysis will reveal a need to protect against both denial of service and password guessing attacks, among others of course.  Blindly following what is an accepted practice for passwords that are encrypted on the client system and applying it to a web application is wrong and will make it difficult to protect againt denial of service attacks.  I don't care how good of a match this technique is for the UNIX password store.  All security is about tradeoffs.

    Finally, your linked article compares the bcrypt method to a method that uses MD5, and one that uses single round DES while potentially not using the full strength of the password to generate the key and using a salt as small as 12 bits.  If the faith you and morbiuswilters have in bcrypt comes only from this analysis, then that's like beating up two eight year old girls and calling yourself the heavyweight champion of the world.  Most of us don't have to pick a solution from the stuff that is pre-installed in the /usr/bin directory.

    One more thing...

    @snover said:

    I would be very very surprised if you were discovering flaws that nobody else has considered

    What makes you think that I think Blowfish has actual cryptographic flaws?  I am opposed to your application of the protocol, not the protocol itself.  I am also opposed to the whole attitude of "this is the best way to do it", without acknowledging that each situation has its own criteria of what makes one solution better than another.  It is impossible for one solution to be the "best" for all situations.



  • What'z the point of having a ztrong pazzword if your uzer name is unzecure?



  • Groan.

    @Jaime said:

    It is also unclear to me why you think I wouldn't know the content of that article and already agree with every word of it.

    Possibly because you said “I couldn't find the implementation details, but I'll bet it's similar to RFC 2898”. What I linked is not an article about bcrypt; if you want one of those, try this article written by someone from a security firm. What I linked is the paper that introduced bcrypt to the world, along with its implementation details.

     

    @Jaime said:

    …instead of discussing the actual issue, whether adding computational expense on server side code is an overall benefit or detriment, you simply left that as assumed…

    I did very explicitly discuss that by saying it was important in the case that the password list was recovered somehow. That outweighs the small additional computational expense on the server, which can be ameliorated by implementing a limit on the number of guesses per time period. I also said that if the standard cost of using bcrypt is too great for you vs. a message digest hash, you can reduce it by lowering the “cost” parameter. But maybe you didn’t read that part?

     

    @Jaime said:

    A SQL injection vulnerability is already worse than a password attack, it allows data modification and possibly privilege escalation.

    A majority of users have a single password and use it on every site they visit. An attack against one site that results in a password list can be far more damaging than privilege escalation on that single site. For someone that talks about performing threat analyses, you’re not thinking very broadly about the potential results of a password crack.

     

    @Jaime said:

    Blindly following what is an accepted practice for passwords that are encrypted on the client system and applying it to a web application is wrong and will make it difficult to protect againt denial of service attacks.
    UNIX is not a “client system”! crypt(3) was originally designed for mainframes! The WWW is not the first time client-server applications have existed!

     

    @Jaime said:

    What makes you think that I think Blowfish has actual cryptographic flaws?

    What makes you think I was talking about Blowfish? I was responding very specifically to your complaint about how using a symmetric encryption system for password hashing is somehow wrong because it involves “jumping through hoops”. This practise of using a symmetric key for password hashing has been used for over 30 years—plenty of time for somebody to discover your hypothetical “other flaws”.


    TL;DR, read the article I linked above.



  • @Jaime said:

    I Googled it.  This is the first paragraph at http://bcrypt.sourceforge.net/

    If you had Googled bcrypt password hashing you would have got: http://www.usenix.org/events/usenix99/provos.html

     

    Way to fail at Google, retard.



  • @Jaime said:

    Look at my handful of posts on this site.

    No.

     

    @Jaime said:

    Almost all are useful answers to difficult questions.

    Considering how wrong you are here, I doubt that.

     

    @Jaime said:

    I am seriously considering making it my hobby to find any opportunity to make your life more difficult.

    You wouldn't be the first.

     

    @Jaime said:

    1.  Using encryption instead of hashing destroys nonrepudiation.  However, you did say that you would store a known plaintext encrypted with the derived key, so that would restore nonrepudiation.  You shouldn't need to go through this many hoops for reasonable security.  I wonder if it has any other flaws that haven't been considered?

    Nonrepudiation?  Of a hashed password?  Dear God.

     

    @Jaime said:

    2.  The decision that Blowfish would be a good idea was based on best practices instead of a threat analysis.  It turns out that this technique isn't useful against a brute-force attack since it is computationally impossible to break any modern enryption by brute force.

    The two points for using bcrypt (or at the very least, "stretched" SHA) are that 1) all digesting hash algorithms have cryptograhpic weaknesses and 2) MD5/SHA alone are not computationally expensive enough.  Since it is a password, the chances of brute forcing are much better than a key.  You seem to be confusing encryption, digital signatures and password hashing.  They all use cryptography, but have different goals.  In the case of password hashing, we want it to be as difficult as possible to find the password.

     

    @Jaime said:

    However, the technique does help against dictionary attacks.  If this were a workstation based application, then a dictionary attack would be a real concern.  A compression tool that supports encryption would benefit greatly from this technique because it would prevent offline dictionary attacks.  But, this is a web based authentication system.  Dictionary attacks are much easier to spot on web sites.  Solving the problem with your solution turns break-ins into DOSes.  That is why it is not a good solution -- it pushes the processor cost onto the web server, not the attacker.

    You really don't seem to understand why passwords are hashed.  Passwords are not hashed to prevent someone from brute forcing the password through the regular login form.  They are hashed so that someone who has access to the hashed form cannot easily find out the password, which might open security vulnerabilities in different systems if the same password is used by the same user elsewhere and would give the attacker access to the system because they know the password, although if they swiped the password DB they probably already owned the system.  Your app should protect against "jackhammering" login attempts, anyway.  Regardless, having a hashed password does not make it any more difficult for someone to break in by guessing; they're just using your CPU time.  What hashing passwords protects against is someone swiping the password DB and then using a brute force attack.  In theory, you can make the hashed passwords public and it will be almost impossible for someone to guess the unhashed password.  bcrypt makes brute forcing very expensive.  MD5 and SHA are significantly less so.

     

    @Jaime said:

    3.  The solution to the nonrepudiation problem from #1 causes a new problem.  Since there is a one to one correlation between the key that was the output of the multi-round Blowfish process and the ciphertext stored as the authentication key, this is now vulnerable to rainbow table attacks.  The more traditional per-record unique salt used along with a good hash algorithm is rainbow table proof.

    bcrypt uses salts.  Obviously you should use salts.  Jesus.

     

    @Jaime said:

    4.  You also mentioned that hash algorithms have cryptographic weaknesses.  I cannot disagree.  However, this is already accounted for.  Just like PKCS isn't secure under 4096 bits due to cryptographic weaknesses, SHA512 still has plenty of strength even after accounting for the history of hash algorithm weaknesses that have shown up in the past.  MD5 is broken, but only totally broken in the chosen-plaintext scenario.  It still has 60 or so bits of security left if someone uses every known shortcut that exploits its flaws in the non-chosen-plaintext scenario.  The infamous RapidSSL MD5 fake SSL certificate was actually created using a limited chosen-plaintext attack and it took about 2^51 brute force attempts.  SHA-1 (a 160 bit algorithm) is down to 63 bits effective security, but it is old.  SHA512 is projected to have plenty of life left and NIST is already working on selecting an algorithm for the SHA-3 family.  Skein would be a good choice to jump on this bandwagon early.

    Password hashing.  Get it through your head.  And SHA will be broken.  All digest hashing algos are.  However, we need them, so we have to live with it.  For password hashing, there is a better way that lets you use much stronger encryption algos instead of hashing.  Once again, proper password hashing algos are computationally expensive; MD5 and SHA are not expensive enough.

     

    @Jaime said:

    It may turn out that I am not on the right side in this discussion.  But, if I am wrong, it will be because of some trade-off that I didn't consider and will have some degree of subjectivity.  I am not a drooling moron and I am not out of my element in this discussion.  I will continue to discuss it rationally if anybody wants to.

    You are wrong.  You may be a drooling moron.  You have not been discussing it rationally.  Either you don't know what you are talking about or you are talking about something other than password hashing.



  • @Jaime said:

    Since all you did was repeat back to me that the only advantage of the bcrypt technique was that it is computationally expensive, I'm not sure why you bothered to go into all that description or to quote a reference that once again states what you and I had already bounced back and forth previously in this thread -- the fact that this technique is computationally expensive.  It is also unclear to me why you think I wouldn't know the content of that article and already agree with every word of it.  However, instead of discussing the actual issue, whether adding computational expense on server side code is an overall benefit or detriment, you simply left that as assumed and added "well if you are have a SQL injection vulnerability, then it can be escalated into a password attack".  A SQL injection vulnerability is already worse than a password attack, it allows data modification and possibly privilege escalation.  That's like locking your fridge so the guy that breaks into your house won't eat your food.

    There are read-only SQL injection exploits.  There are also plenty of ways to get the password other than SQL injection.

     

    @Jaime said:

    Ley me say this unequivocally so that we don't need to hash it out again -- I agree that it is important to make it computationally expensive to mount a dictionary attack on a client-installed system.  Unfortunately, we are not discussing a client-installed system on this thread.

    Why would you not make it as secure on a server system?

     

    @Jaime said:

    Blindly following what is an accepted practice for passwords that are encrypted on the client system and applying it to a web application is wrong and will make it difficult to protect againt denial of service attacks.

    You are a retard.  You're seriously suggesting somebody shouldn't use a proper password hashing scheme because it might be subject to a DoS?  Christ.  Somebody can DoS your shitty password scheme, too.

     

    @Jaime said:

    Finally, your linked article compares the bcrypt method to a method that uses MD5, and one that uses single round DES while potentially not using the full strength of the password to generate the key and using a salt as small as 12 bits.  If the faith you and morbiuswilters have in bcrypt comes only from this analysis, then that's like beating up two eight year old girls and calling yourself the heavyweight champion of the world.  Most of us don't have to pick a solution from the stuff that is pre-installed in the /usr/bin directory.

    You're losing.  Badly.

     

    @Jaime said:

    What makes you think that I think Blowfish has actual cryptographic flaws?  I am opposed to your application of the protocol, not the protocol itself.  I am also opposed to the whole attitude of "this is the best way to do it", without acknowledging that each situation has its own criteria of what makes one solution better than another.  It is impossible for one solution to be the "best" for all situations.

    Depends on the solution and the problem.  For the problem domain of password hashing, bcrypt is very secure.  More secure than MD5 or SHA.  It may not be the best, but it's damn close.  Obviously, there are cases where bcrypt would not work well.  This is not one of them.  Give it up.  You lost.



  • @snover said:

    I was responding very specifically to your complaint about how using a symmetric encryption system for password hashing is somehow wrong because it involves “jumping through hoops”. This practise of using a symmetric key for password hashing has been used for over 30 years—plenty of time for somebody to discover your hypothetical “other flaws”.

    Give it up.  The guy read "Web Security For Fucking Retards" and now thinks he knows more about password hashing than everyone else.  Clearly, he wrote several systems that used MD5 or SHA and now he's trying to save face by claiming they are the most securestest.  I pointed out everything he needed to know to look into it for himself long ago.  He instead chose to open up Applied Cryptography to the index and randomly pick words to throw around.  See, symmetric encryption is no good for password hashing because the output could be repudiated!  Somebody might try to claim that their password isn't actually their password and there's no way to prove it mathematically!  Oh noes!



  • @Scarlet Manuka said:

    What'z the point of having a ztrong pazzword if your uzer name is unzecure?

    Hey, bub, even I know the value of good zecurity!



  • @snover said:

    A majority of users have a single password and use it on every site they visit. An attack against one site that results in a password list can be far more damaging than privilege escalation on that single site. For someone that talks about performing threat analyses, you’re not thinking very broadly about the potential results of a password crack.
     

    QFT



  • This is a really stupid thing to have a flamewar over.

    Let's just agree that the best password hashing mechanism is ROT-13 and be done with it.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Let's just agree that the best password hashing mechanism is ROT-13 and be done with it.
    Twice.



  •  @PJH said:

    Twice.

     

    I always do it twice.

    ... and then I might ROT-13 my password as well.



  • @PJH said:

    @blakeyrat said:
    Let's just agree that the best password hashing mechanism is ROT-13 and be done with it.
    Twice.
    I prefer to ROT-6.5 four times.



  • @bstorer said:

    @PJH said:
    @blakeyrat said:
    Let's just agree that the best password hashing mechanism is ROT-13 and be done with it.
    Twice.
    I prefer to ROT-6.5 four times.
    You should ROT-1 1000 times.  It's more computationally expensive.  Don't you know anything? 



  • @belgariontheking said:

    You should ROT-1 1000 times.  It's more computationally expensive.  Don't you know anything?
    Don't you mean ROT-26, 1000 times?



  • @bstorer said:

    @PJH said:

    @blakeyrat said:
    Let's just agree that the best password hashing mechanism is ROT-13 and be done with it.
    Twice.
    I prefer to ROT-6.5 four times.

    Just translate the password to Linear A.  Nobody has ever been able to decipher it.



  •  @morbiuswilters said:

    @bstorer said:

    @PJH said:

    @blakeyrat said:
    Let's just agree that the best password hashing mechanism is ROT-13 and be done with it.
    Twice.
    I prefer to ROT-6.5 four times.

    Just translate the password to Linear A.  Nobody has ever been able to decipher it.

    And risk it falling into the hands of an ancient Cretan with a grudge against me?  Nice try, buddy, but I've seen that scam before.


  • @bstorer said:

     @morbiuswilters said:

    @bstorer said:

    @PJH said:

    @blakeyrat said:
    Let's just agree that the best password hashing mechanism is ROT-13 and be done with it.
    Twice.
    I prefer to ROT-6.5 four times.

    Just translate the password to Linear A.  Nobody has ever been able to decipher it.

    And risk it falling into the hands of an ancient Cretan with a grudge against me?  Nice try, buddy, but I've seen that scam before.
     

    Better than an ancient cretin with a grudge against you.



  • @morbiuswilters said:

    Just translate the password to Linear A.  Nobody has ever been able to decipher it.

    That's security by obscurity!



  • @dhromed said:

    @morbiuswilters said:

    Just translate the password to Linear A.  Nobody has ever been able to decipher it.

    That's security by obscurity!

    Well, it's still better than MD5.



  • @Jaime said:

    Standard .Net setup of an AES encrytor/decryptor:

    string password = "passwordofanylengthwillworkhere";
    RijndaelManaged alg = new RijndaelManaged();
    byte[] salt = Encoding.ASCII.GetBytes("salttomakerainbowtableslesseffective");
    Rfc2898DeriveByes key = new Rfc2898DeriveBytes(password, salt);
    alg.Key = key.GetBytes(alg.KeySize / 8);
    alg.IV = key.GetBytes(alg.BlockSize / 8);

     

    Jeff Atwood strikes again.  I think he single-handedly set the world of computer security back 20 years with one stupid blog post.



  • @Aaron said:

    @Jaime said:

    Standard .Net setup of an AES encrytor/decryptor:

    string password = "passwordofanylengthwillworkhere";
    RijndaelManaged alg = new RijndaelManaged();
    byte[ salt = Encoding.ASCII.GetBytes("salttomakerainbowtableslesseffective");
    Rfc2898DeriveByes key = new Rfc2898DeriveBytes(password, salt);
    alg.Key = key.GetBytes(alg.KeySize / 8);
    alg.IV = key.GetBytes(alg.BlockSize / 8);

     

    Jeff Atwood strikes again.  I think he single-handedly set the world of computer security back 20 years with one stupid blog post.

    LOL, I didn't see that until you pointed it out.



  • @Aaron said:

    @Jaime said:

    Standard .Net setup of an AES encrytor/decryptor:

    string password = "passwordofanylengthwillworkhere";
    RijndaelManaged alg = new RijndaelManaged();
    byte[ salt = Encoding.ASCII.GetBytes("salttomakerainbowtableslesseffective");
    Rfc2898DeriveByes key = new Rfc2898DeriveBytes(password, salt);
    alg.Key = key.GetBytes(alg.KeySize / 8);
    alg.IV = key.GetBytes(alg.BlockSize / 8);

     

    Jeff Atwood strikes again.  I think he single-handedly set the world of computer security back 20 years with one stupid blog post.

     

    Care to provide a link to said blog post? I'm not familiar with it, though from what I know about Atwood it doesn't surprise me.



  • @Someone You Know said:

    @Aaron said:
    @Jaime said:
    Standard .Net setup of an AES encrytor/decryptor:

    string password = "passwordofanylengthwillworkhere";
    RijndaelManaged alg = new RijndaelManaged();
    byte[ salt = Encoding.ASCII.GetBytes("salttomakerainbowtableslesseffective");
    Rfc2898DeriveByes key = new Rfc2898DeriveBytes(password, salt);
    alg.Key = key.GetBytes(alg.KeySize / 8);
    alg.IV = key.GetBytes(alg.BlockSize / 8);

    Jeff Atwood strikes again.  I think he single-handedly set the world of computer security back 20 years with one stupid blog post.
    Care to provide a link to said blog post? I'm not familiar with it, though from what I know about Atwood it doesn't surprise me.
    Presumably, it's this one or this one.

    Also, I was told that .NET was supposed to make things less verbose, that example looks needlessly complicated. Wouldn't a simple:
       string salt = binStreamToHexString(fread("/dev/urandom", 128));
       string hashed_password = HASH_ALGO(salt, password);
    

    be clearer? (Replace the functions with whatever does what the name says it does)



  • @morbiuswilters said:

    Well, it's still better than MD5.

    It's funny 'cuz it's true.

    @Someone You Know said:

    Care to provide a link to said blog post?

    This one, I believe.

    I used to be a fan of Jeff, until he tried to be a security expert. Now I just read Raymond Chen's blog; at least he doesn't step outside his area of expertise whenever he posts.


Log in to reply