5 ms·

But this is why we do one or both things: strip obvious things from hashed password and store them separately or add a trivial character reshuffling algorithm.

by aadamov 14y ago

But this is why we do one or both things: strip obvious things from hashed password and store them separately or add a trivial character reshuffling algorithm. The point is that hacker would not only have to steal your hashed passwords, but also steal and understand your code. Makes it more complicated.

raverbashing 14y ago
No The security of your system can never depend on an attacker not knowing the implementation. Or: Security through obscurity (is no security) Using gimmicks like for example shuffling some characters in the hash may delay some attacks. But the problem is that these techniques are usually done on systems that have no sufficient security. Have a big salt and use PBKDF2 or Bcrypt and you know the exact difficulty of getting the passwords.
- archivator 14y ago
  If you need a citable name, taking the transparency of the cryptosystem as an assumption is called Kerckhoffs's principle.
- cschneid 14y ago
  IMO, you should be doing both. People should use strong bcrypted passwords, with a salt, then ALSO a 'secret' pepper value (long value stored in app code). This adds additional security in the case of a db-only dump being released, and doesn't harm the strength or a full code+db release at all either. Stripping off identifying info from hashes like talked about in this thread doesn't weaken the hash in any way, but instead makes it another thing to figure out by an attacker. At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected. Security is about depth, not putting 100% of your trust in a single algorithm. Even if that algorithm is well trusted. It's simply not an either/or.
  - aadamov 14y ago
    Indeed, the assumption is that attacker has limited window of opportunity to grab the data. Taking that as a base assumption, it would make sense two store parts of the hashed password in two separate databases on two separate machines. Hacker would have to gain access to both. My initial alternative was to add some trick inside of the code, like a simple shuffling of characters. Assuming that code is not stored on the same machine as DB that should increase security considerably. But either concept would work. Of course it does not remove the need for higher degree of difficulty for hashing itself.
  - pixl97 14y ago
    With publicly creatable accounts by the potential hacker, a pepper is just another password. Leaving identifiable bits in the hash makes it easier to do things like if pass_type ($1$) { on_logon $upgrade_to_pass_type$6$) > At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected. If you ever know at all. Better to use 'not fast' hashes like bcrypt, scrypt, or PB(something) that requires far more work and far slower cracking.
    - cschneid 14y ago
      Re pepper: It's a STRONG password. It turns '12345' into 64 random characters + '12345'. Meaning that you can't brute force against a dictionary, unless you have that pepper value. Which is only stored on the production system. This turns a well-known attack vector of "developer loses a data dump" into something that won't expose passwords. Re hash: yeah, use a strong hash function. Never advocated otherwise. Defense in depth is awesome, and not to be ignored. Just like we secure the database with a password, in addition to securing the server (with ssh keys), in addition to keeping software up to date, in addition to rate-limiting online password attempts, in addition to... well, you get the idea. Protect at every level. Make the attacker work as hard as possible.
  - raverbashing 14y ago
    Let me try to explain this better Suppose you're doing the byte shuffling right? Or you split the hash value in two and you concatenate them in the reverse order, something like that. Now here's the thing: if you have a determined attacker, they will figure out your code does that. So you gain no extra security from it For a casual attacker this may be a bigger deterrent. Now, this casual attacker may try to create (or already has) an account, for which the password is known. So he goes and compares it trying to figure out your encryption mechanism It's slightly more difficult than the guy that just used MD5 to hash the passwords (let's assume that's the minimum security people use - "in theory") So, it's all fine and dandy until you have another 'increase the security' idea that actually decreases the security. And this is more common than you think. Example: taking the hash and encrypting it (for some choices of hash and encryption) (Not to mention when people think that because they use this 'improved security scheme' that they invented they can be lax in security elsewhere in the chain)
    - cschneid 14y ago
      You're right. Throwing shit at the wall can screw things up, and you must still be using a proper full-strength hash, and not just throw crypto primitives at it. What I'm suggesting is that secrecy is a useful layer on top of a valid cryptography approach. What you can do is that you can have the inputs to your hash function come from several places. User password, a salt per-password to protect against rainbow table attacks, a pepper forces an attacker to get both the application code, AND the database dump. So it's bcrypt(password + salt + pepper). If you don't know the pepper, all of a sudden you have a 128+ character totally random password to break, instead of the user's totally insecure '12345'. And in the case that you have the application code broken (ie, attacker gets the production code), well, then you're still using bcrypt, so no problem. That step would protect against the common "db dump stolen off a dev's laptop" attack. Since the pepper only exists in production. So yea, you're right that you can't just make shit up and hope for the best. But separating the data that needs to be stolen strengthens your overall defense.
- nawitus 14y ago
  Using a big salt is essentially the same as using a secret character shuffling algorithm. The difference is that the salt value is thought to be on the 'data side' and not in the code side, so it's allowed to be secret. The distinction is pretty arbitrary, though.
brown9-2 14y ago
If someone can steal your passwords, doesn't it follow that they'd more than likely also have stolen your code?

by aadamov 14y ago

raverbashing 14y ago

No The security of your system can never depend on an attacker not knowing the implementation. Or: Security through obscurity (is no security) Using gimmicks like for example shuffling some characters in the hash may delay some attacks. But the problem is that these techniques are usually done on systems that have no sufficient security. Have a big salt and use PBKDF2 or Bcrypt and you know the exact difficulty of getting the passwords.

archivator 14y ago
If you need a citable name, taking the transparency of the cryptosystem as an assumption is called Kerckhoffs's principle.
cschneid 14y ago
IMO, you should be doing both. People should use strong bcrypted passwords, with a salt, then ALSO a 'secret' pepper value (long value stored in app code). This adds additional security in the case of a db-only dump being released, and doesn't harm the strength or a full code+db release at all either. Stripping off identifying info from hashes like talked about in this thread doesn't weaken the hash in any way, but instead makes it another thing to figure out by an attacker. At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected. Security is about depth, not putting 100% of your trust in a single algorithm. Even if that algorithm is well trusted. It's simply not an either/or.
- aadamov 14y ago
  Indeed, the assumption is that attacker has limited window of opportunity to grab the data. Taking that as a base assumption, it would make sense two store parts of the hashed password in two separate databases on two separate machines. Hacker would have to gain access to both. My initial alternative was to add some trick inside of the code, like a simple shuffling of characters. Assuming that code is not stored on the same machine as DB that should increase security considerably. But either concept would work. Of course it does not remove the need for higher degree of difficulty for hashing itself.
- pixl97 14y ago
  With publicly creatable accounts by the potential hacker, a pepper is just another password. Leaving identifiable bits in the hash makes it easier to do things like if pass_type ($1$) { on_logon $upgrade_to_pass_type$6$) > At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected. If you ever know at all. Better to use 'not fast' hashes like bcrypt, scrypt, or PB(something) that requires far more work and far slower cracking.
  - cschneid 14y ago
    Re pepper: It's a STRONG password. It turns '12345' into 64 random characters + '12345'. Meaning that you can't brute force against a dictionary, unless you have that pepper value. Which is only stored on the production system. This turns a well-known attack vector of "developer loses a data dump" into something that won't expose passwords. Re hash: yeah, use a strong hash function. Never advocated otherwise. Defense in depth is awesome, and not to be ignored. Just like we secure the database with a password, in addition to securing the server (with ssh keys), in addition to keeping software up to date, in addition to rate-limiting online password attempts, in addition to... well, you get the idea. Protect at every level. Make the attacker work as hard as possible.
- raverbashing 14y ago
  Let me try to explain this better Suppose you're doing the byte shuffling right? Or you split the hash value in two and you concatenate them in the reverse order, something like that. Now here's the thing: if you have a determined attacker, they will figure out your code does that. So you gain no extra security from it For a casual attacker this may be a bigger deterrent. Now, this casual attacker may try to create (or already has) an account, for which the password is known. So he goes and compares it trying to figure out your encryption mechanism It's slightly more difficult than the guy that just used MD5 to hash the passwords (let's assume that's the minimum security people use - "in theory") So, it's all fine and dandy until you have another 'increase the security' idea that actually decreases the security. And this is more common than you think. Example: taking the hash and encrypting it (for some choices of hash and encryption) (Not to mention when people think that because they use this 'improved security scheme' that they invented they can be lax in security elsewhere in the chain)
  - cschneid 14y ago
    You're right. Throwing shit at the wall can screw things up, and you must still be using a proper full-strength hash, and not just throw crypto primitives at it. What I'm suggesting is that secrecy is a useful layer on top of a valid cryptography approach. What you can do is that you can have the inputs to your hash function come from several places. User password, a salt per-password to protect against rainbow table attacks, a pepper forces an attacker to get both the application code, AND the database dump. So it's bcrypt(password + salt + pepper). If you don't know the pepper, all of a sudden you have a 128+ character totally random password to break, instead of the user's totally insecure '12345'. And in the case that you have the application code broken (ie, attacker gets the production code), well, then you're still using bcrypt, so no problem. That step would protect against the common "db dump stolen off a dev's laptop" attack. Since the pepper only exists in production. So yea, you're right that you can't just make shit up and hope for the best. But separating the data that needs to be stolen strengthens your overall defense.
nawitus 14y ago
Using a big salt is essentially the same as using a secret character shuffling algorithm. The difference is that the salt value is thought to be on the 'data side' and not in the code side, so it's allowed to be secret. The distinction is pretty arbitrary, though.

brown9-2 14y ago

If someone can steal your passwords, doesn't it follow that they'd more than likely also have stolen your code?