5 ms·

That's not how a properly implemented hash -- and cryptography in general -- is supposed to work. This strategy is called "security by obscurity", and is seen

by lucastx 13y ago

That's not how a properly implemented hash -- and cryptography in general -- is supposed to work. This strategy is called "security by obscurity", and is seen as a very bad one. Instead, cryptography aims to provide means to encrypt data in a way that anyone knows //how// it was encrypted, and still doesn't have a clue how to decrypt it -- because they don't have the key, in case of encryption, and because the hash is a "one-way" function, in case of hashing.

hga 13y ago
Disagree for systems. I take adding "security through obscurity" to the normal standard good methods as a defense in depth measure.
- jleader 13y ago
  Adding "security through obscurity" is only a net win over "published security scheme" if your engineers are substantially better than any engineers who might comment on your published scheme. Even if you've hired world-class security engineers, there could still be some flaw they've overlooked, that an outside commentator might notice. Note that the security of a whole system is harder to get right than the security of any one component; keeping it obscure just makes it much less likely that a white hat will notice the flaw and notify you. A simple example of this is the freshman CS majors' perennial idea that combining multiple PRNGs will yield a "more random" algorithm (it typically makes the result easier to predict). There are plenty of cases of a secure algorithm being used to build a system that ends up insecure because of some obscure flaw that nobody noticed initially.
  - hga 13y ago
    "Adding "security through obscurity" is only a net win over "published security scheme" if your engineers are substantially better than any engineers who might comment on your published scheme." I think that overstates the case. Your engineers don't have to be better, just good enough know what's correct and safe, or do research until they know. My approach is to just add things that are clearly correct to published and studied systems that are thought to be correct. In this case, we're talking about applying multiple or multiple runs of one way hashing functions; I'd actually do some research before trying the latter, but it strikes me as safe, and the former is by definition safe, right? Whereas it would never even occur to me to combine PRNGs ... or not use a hardware source of entropy to begin with in the first place (they aren't that expensive in the scheme of things).
- yaur 13y ago
  and that is exactly how we get clowns like linkedin storing all of their passwords as unsalted hashes...
  - hga 13y ago
    See my other comment on starting with "published and studied systems that are thought to be correct". Salting your passwords has been state of the art for so long I can't remember when I first heard of it. LinkedIn was not adding any sort of reasonable defense in depth security through obscurity, but foundational gross negligence.

by lucastx 13y ago

hga 13y ago

Disagree for systems. I take adding "security through obscurity" to the normal standard good methods as a defense in depth measure.

jleader 13y ago
Adding "security through obscurity" is only a net win over "published security scheme" if your engineers are substantially better than any engineers who might comment on your published scheme. Even if you've hired world-class security engineers, there could still be some flaw they've overlooked, that an outside commentator might notice. Note that the security of a whole system is harder to get right than the security of any one component; keeping it obscure just makes it much less likely that a white hat will notice the flaw and notify you. A simple example of this is the freshman CS majors' perennial idea that combining multiple PRNGs will yield a "more random" algorithm (it typically makes the result easier to predict). There are plenty of cases of a secure algorithm being used to build a system that ends up insecure because of some obscure flaw that nobody noticed initially.
- hga 13y ago
  "Adding "security through obscurity" is only a net win over "published security scheme" if your engineers are substantially better than any engineers who might comment on your published scheme." I think that overstates the case. Your engineers don't have to be better, just good enough know what's correct and safe, or do research until they know. My approach is to just add things that are clearly correct to published and studied systems that are thought to be correct. In this case, we're talking about applying multiple or multiple runs of one way hashing functions; I'd actually do some research before trying the latter, but it strikes me as safe, and the former is by definition safe, right? Whereas it would never even occur to me to combine PRNGs ... or not use a hardware source of entropy to begin with in the first place (they aren't that expensive in the scheme of things).
yaur 13y ago
and that is exactly how we get clowns like linkedin storing all of their passwords as unsalted hashes...
- hga 13y ago
  See my other comment on starting with "published and studied systems that are thought to be correct". Salting your passwords has been state of the art for so long I can't remember when I first heard of it. LinkedIn was not adding any sort of reasonable defense in depth security through obscurity, but foundational gross negligence.