Ondrej Kelle I use KeePassX (written in QT while KeePass 2.x is written in .net), for its performance - especially when I was using my non-SSD PC, I copy password from it so many times that the performance really matters. And this is how my passwords look like: 7xbj5dnxERdBo5NNKJ8nB7sDHnHGrrAR3JqxCL9T
shouldn't the keeper of my password just change one bit in the, lets say MD5 hash, so it's "almost" MD5 hash, but because it's not standard, it won't be cracked that way, not standard, hmm??
Willem Weideman That's security by obscurity (i.e. no security at all). There are plenty of properly secure protocols to choose from. MD5 is not and has been broken for many years now.
You should never ever try to create your own cryptography because crypto is by far the hardest part of IT (and perhaps all of science). Rely on the advice of experts (like bruce schneier) instead.
Security by obscurity alone is wrong. But as 1 additional layer of the security stack is fine. SHA 512 is "secure enough" today. Will it be in 10 years? I doubt it. There is nothing wrong in using SHA 512 + change the order of a few bits... or adding some garbage to it...
Yes, and salting is just one more layer of the stack. The "open security" thing is a myth. There is nothing wrong in adding more tricks to standard stuff.
anybody cares to explain the stack? I presume salting is obscuring the password with hashing, but what was the video all about then? I thought he was explaining how to crack passwords from the hash, if the hash isn't standard, how would a brute force attack like that make any sense then?
Willem Weideman because many sites use(d) plain md5 or sha-1 hashing and many people re-use password. So if you crack an account on one not so well configured site, then you have a lot of opportunities on other sites. Remember: a database with hashes obtained a few years ago probably uses weaker algorithms and can be increasingly easier to crack over time.
Jeroen Wiert Pluimers so if you're hash is unique (bits of the standard hash flipped), it's not going to match the not so well configured site's plain hash
Alexandre Machado Agreed - adding an additional customized layer on top of standard/proven hashes makes your hashes, if exposed, un-matcheable to published dictionaries and defeats one of the common attack methods. Always use salt (and pepper) and then add your own twist.
Darian Miller No, this will only end in tears. They way to go is to use a slow crypographical hash as per current best practise (salted etc). Do not roll your own based on poor protocols. Everybody seems to think they understand this stuff, you don't. reverse engineering your twist is trivial and now you've based your 133t scheme on MD5, whereas you could have been using a secure hash. Use PBKDF2, bcrypt or scrypt for password storage. see: https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet
And for God's sake stop trying to reinvent the wheel.
Johan Bontes OK Johan, interesting, so what you're saying is the hash algorithms, lets use MD5 for example, is "mathematically" more secure than a self rolled hash based upon the MD5 algorithm? And that is reinventing the wheel? (rolling your own)
And this might be too broad, but how would one go about reverse engineering a hash algorithm?
In this case, Willem Weideman , I think that Johan Bontes is wrong. Read this, please https://danielmiessler.com/study/security-by-obscurity/ It has a perfect example of what I'm talking about: The M-1 tank camouflage. Why M-1 tanks are are not red? Nobody is telling you that you should design your own hashing algorithm. That's absurd. However, once you are using standard secure algorithms, let's say SHA 512, there is nothing wrong adding additional stuff over it.
Willem Weideman You're not getting my point. My point is that you need to start with a secure algorithm. (i.e. scrypt, bcrypt or pbkdf2) all other hashing algorithms are not secure, because they are too fast (i.e. too easy to crack).
If you use a properly secured algorithm + salt then your obfuscation is pointless and not needed. An unsecure hash + obfuscation is still unsecure, because the obfuscation is easy to reverse engineer.
It's trivial to detect which hashing algorithm is used by searching for the magic numbers that these algorithms use in the source/binary code.
Alexandre Machado The hash is not a 'detail' it is the very core of the issue. Once you use a secure hash + secure way of salting, you are done, nothing else is needed. The other way round, nothing will fix an unsecure starting point. Ergo your concept is flawed and pwnage is sure to follow.
Alexandre Machado Let me explain why I disagree. An example: I always run my ssh on port 32. This is great because if I were to run in on port 22 (the default) I get 100's of login attempts per day. On port 32 no-one tries to hack my SSH server. Great, more security by layering obscurity. I still need to use secure practises.
Onwards to hashes. If I start with an insecure hash, I cannot upgrade it later. My app and 117 million accounts (e.g.: linkedin) are locked into SHA1. It's very hard to change this (unlike my ssh-server which I can just apt-upgrade - rcsshd restart). So your approach locks me into an insecure hash because you're relying on obscurity whereas you should have been focused on getting the core secure. The fact that you (and the other 99.9% of planet earth) think that SHA512 is a secure hash is a big part of that problem.
The obscurity actually hinders here because it makes the hashes even harder to migrate than they already are.
Johan Bontes I used SHA 512 as an example because that's one of alternative hashes that the guy on the video mentioned. The hash algorithm that you should use depend on what you are doing and I won't tell you what you should or should not use. Period. However, you are just doing what the other guy said in the text: "Those who dismiss this concept out of hand are simply regurgitating someone else’s (wrong) ideas rather than working through the concepts themselves."
Johan Bontes it's pretty easy to upgrade to a new has. Add a more secure hash. Ensure your system can use both hashes. Each time a user logs in using the less secure hash, store the more secure hash and delete the less secure one. Notify your users you're phasing out the old hash soon and when they have not logged in by a certain date they will have to request new credentials.
Darian Miller Alexandre Machado I disagree that adding additional stuff over standard hashing makes it more secure as it's really hard to prove you've done it right and it makes it a lot harder to accept hashes from different platforms (you'd have to sync your additions and prove the implementations across those platforms).
Existing hashing solutions provide more than enough parameterisations to ensure you're hashes are slightly different than your neighbours.
If you want Embarcadero to upgrade their community password system you need to find a Joomla plugin with the capabilities that you want and then submit it as a bug in the quality portal for the community site.
Sorry, but Jeroen Wiert Pluimers and Johan Bontes you are missing the point. Use as secure of a standard hash routine as you deem suitable, say bcrypt with with a huge iteration count so it takes multiple seconds per hash on your best equipment (no one is saying that you should ever bit twiddle MD5...not sure where that assumption came from.) There is absolutely nothing wrong with adding a little customization to the end of the routine. In fact, if you two were arguing this same way back when MD5 was king, then this video that we are commenting on shows how you would have been wrong to stick with the standard. There's always better techniques/equipment coming out to hammer existing routines. One prime example that you can consider: say you maintain monthly tape backups from a few years ago (or from just the other day before you first watched the video - most businesses maintain backups at least for a few years, much often longer) where the database contained MD5 hashed passwords and the tape backups were just compromised this morning (say an angry employee just uploaded the data to a public file sharing site out of spite.) Now, watch the video to see how easily this data would be attacked. Wouldn't it be worth some additional effort today in order to prevent a healthy percentage of the attackers from easily compromising your data in the future due to new research/tools/technology increases? The vast majority of hackers use commonly available tools to attack standardized routines. I would assume that fact would be the same in the future. So for some sake of some perceived purity today you are risking your data tomorrow from one very realistic possible avenue of attack. Even the best bcrypted stored hash from today is guaranteed to be crackable sometime in the future (if not already today by those much smarter than us with a lot more resources.) Do you think the securability of the stored hashes will always outlast the storage life of the backed up data? People are creatures of habit...which is why some of us enforce rules like not allowing users to reuse the same password from the last 6 utilized (and even then some really stubborn people change their password 7 times to get around that requirement.) Not many sites enforce such restrictions, so there shouldn't be any discount given to a password that is a few years old. For example, LinkedIn's breach is from 2012 and that password list is still being utilized by hackers today.
Jeroen Wiert Pluimers it is not that easy to upgrade a password hash, the user notification process alone will be complicated (lost emails and all that jazz), some users will not want to do it without getting explanation (which they often cannot understand), so it can become very messy if you have a sizable user base.
For instance Ashley Madison had upgraded from MD5 to bcrypt, but that left old passwords vulnerable:
That said, I consider that any "Vanilla" security is in practice very weak, simply because weaknesses will be found in standards, and sooner or later they will not be patched or updated fast enough.. at which point the whole affair becomes vulnerable to automated hacking tools and bots.
scary, and cool at the same time :-)
ReplyDeletemy idea of a secure password is completely shattered
ReplyDeleteI use KeePass random password generator: http://keepass.info/
ReplyDeleteOndrej Kelle I use KeePassX (written in QT while KeePass 2.x is written in .net), for its performance - especially when I was using my non-SSD PC, I copy password from it so many times that the performance really matters. And this is how my passwords look like: 7xbj5dnxERdBo5NNKJ8nB7sDHnHGrrAR3JqxCL9T
ReplyDeleteEdwin Yip
ReplyDeleteThanks. In my experience, performance is OK with KeePass. I just keep it running all the time.
shouldn't the keeper of my password just change one bit in the, lets say MD5 hash, so it's "almost" MD5 hash, but because it's not standard, it won't be cracked that way, not standard, hmm??
ReplyDeleteWillem Weideman
ReplyDeleteThat's security by obscurity (i.e. no security at all). There are plenty of properly secure protocols to choose from. MD5 is not and has been broken for many years now.
You should never ever try to create your own cryptography because crypto is by far the hardest part of IT (and perhaps all of science). Rely on the advice of experts (like bruce schneier) instead.
Willem Weideman don't try the security by obscurity thing!
ReplyDeleteSecurity by obscurity alone is wrong. But as 1 additional layer of the security stack is fine. SHA 512 is "secure enough" today. Will it be in 10 years? I doubt it. There is nothing wrong in using SHA 512 + change the order of a few bits... or adding some garbage to it...
ReplyDeleteAlexandre Machado that's what salting is for.
ReplyDeleteYes, and salting is just one more layer of the stack. The "open security" thing is a myth. There is nothing wrong in adding more tricks to standard stuff.
ReplyDeleteanybody cares to explain the stack? I presume salting is obscuring the password with hashing, but what was the video all about then? I thought he was explaining how to crack passwords from the hash, if the hash isn't standard, how would a brute force attack like that make any sense then?
ReplyDeleteWillem Weideman because many sites use(d) plain md5 or sha-1 hashing and many people re-use password. So if you crack an account on one not so well configured site, then you have a lot of opportunities on other sites.
ReplyDeleteRemember: a database with hashes obtained a few years ago probably uses weaker algorithms and can be increasingly easier to crack over time.
Jeroen Wiert Pluimers so if you're hash is unique (bits of the standard hash flipped), it's not going to match the not so well configured site's plain hash
ReplyDeleteAlexandre Machado Agreed - adding an additional customized layer on top of standard/proven hashes makes your hashes, if exposed, un-matcheable to published dictionaries and defeats one of the common attack methods. Always use salt (and pepper) and then add your own twist.
ReplyDeleteDarian Miller
ReplyDeleteNo, this will only end in tears. They way to go is to use a slow crypographical hash as per current best practise (salted etc). Do not roll your own based on poor protocols. Everybody seems to think they understand this stuff, you don't. reverse engineering your twist is trivial and now you've based your 133t scheme on MD5, whereas you could have been using a secure hash. Use PBKDF2, bcrypt or scrypt for password storage. see: https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet
And for God's sake stop trying to reinvent the wheel.
Johan Bontes OK Johan, interesting, so what you're saying is the hash algorithms, lets use MD5 for example, is "mathematically" more secure than a self rolled hash based upon the MD5 algorithm? And that is reinventing the wheel? (rolling your own)
ReplyDeleteAnd this might be too broad, but how would one go about reverse engineering a hash algorithm?
In this case, Willem Weideman , I think that Johan Bontes is wrong. Read this, please https://danielmiessler.com/study/security-by-obscurity/
ReplyDeleteIt has a perfect example of what I'm talking about: The M-1 tank camouflage. Why M-1 tanks are are not red?
Nobody is telling you that you should design your own hashing algorithm. That's absurd. However, once you are using standard secure algorithms, let's say SHA 512, there is nothing wrong adding additional stuff over it.
Alexandre Machado
ReplyDeleteSHA512 is not a secure hashing algorithm. See the owasp reference above.
Johan Bontes replace SHA 512 by anything you like. I'm talking about the concept, not the implementation.
ReplyDeleteWillem Weideman
ReplyDeleteYou're not getting my point. My point is that you need to start with a secure algorithm. (i.e. scrypt, bcrypt or pbkdf2) all other hashing algorithms are not secure, because they are too fast (i.e. too easy to crack).
If you use a properly secured algorithm + salt then your obfuscation is pointless and not needed.
An unsecure hash + obfuscation is still unsecure, because the obfuscation is easy to reverse engineer.
It's trivial to detect which hashing algorithm is used by searching for the magic numbers that these algorithms use in the source/binary code.
Alexandre Machado
ReplyDeleteThe hash is not a 'detail' it is the very core of the issue. Once you use a secure hash + secure way of salting, you are done, nothing else is needed. The other way round, nothing will fix an unsecure starting point.
Ergo your concept is flawed and pwnage is sure to follow.
Johan Bontes did you read the page I mentioned? I guess not....
ReplyDeleteAlexandre Machado
ReplyDeleteLet me explain why I disagree.
An example: I always run my ssh on port 32. This is great because if I were to run in on port 22 (the default) I get 100's of login attempts per day.
On port 32 no-one tries to hack my SSH server.
Great, more security by layering obscurity.
I still need to use secure practises.
Onwards to hashes.
If I start with an insecure hash, I cannot upgrade it later.
My app and 117 million accounts (e.g.: linkedin) are locked into SHA1. It's very hard to change this (unlike my ssh-server which I can just apt-upgrade - rcsshd restart).
So your approach locks me into an insecure hash because you're relying on obscurity whereas you should have been focused on getting the core secure.
The fact that you (and the other 99.9% of planet earth) think that SHA512 is a secure hash is a big part of that problem.
The obscurity actually hinders here because it makes the hashes even harder to migrate than they already are.
Johan Bontes I used SHA 512 as an example because that's one of alternative hashes that the guy on the video mentioned. The hash algorithm that you should use depend on what you are doing and I won't tell you what you should or should not use. Period. However, you are just doing what the other guy said in the text: "Those who dismiss this concept out of hand are simply regurgitating someone else’s (wrong) ideas rather than working through the concepts themselves."
ReplyDeleteJohan Bontes it's pretty easy to upgrade to a new has. Add a more secure hash. Ensure your system can use both hashes. Each time a user logs in using the less secure hash, store the more secure hash and delete the less secure one. Notify your users you're phasing out the old hash soon and when they have not logged in by a certain date they will have to request new credentials.
ReplyDeleteDarian Miller Alexandre Machado I disagree that adding additional stuff over standard hashing makes it more secure as it's really hard to prove you've done it right and it makes it a lot harder to accept hashes from different platforms (you'd have to sync your additions and prove the implementations across those platforms).
Existing hashing solutions provide more than enough parameterisations to ensure you're hashes are slightly different than your neighbours.
If you want Embarcadero to upgrade their community password system you need to find a Joomla plugin with the capabilities that you want and then submit it as a bug in the quality portal for the community site.
ReplyDeleteSorry, but Jeroen Wiert Pluimers and Johan Bontes you are missing the point. Use as secure of a standard hash routine as you deem suitable, say bcrypt with with a huge iteration count so it takes multiple seconds per hash on your best equipment (no one is saying that you should ever bit twiddle MD5...not sure where that assumption came from.) There is absolutely nothing wrong with adding a little customization to the end of the routine. In fact, if you two were arguing this same way back when MD5 was king, then this video that we are commenting on shows how you would have been wrong to stick with the standard. There's always better techniques/equipment coming out to hammer existing routines. One prime example that you can consider: say you maintain monthly tape backups from a few years ago (or from just the other day before you first watched the video - most businesses maintain backups at least for a few years, much often longer) where the database contained MD5 hashed passwords and the tape backups were just compromised this morning (say an angry employee just uploaded the data to a public file sharing site out of spite.) Now, watch the video to see how easily this data would be attacked. Wouldn't it be worth some additional effort today in order to prevent a healthy percentage of the attackers from easily compromising your data in the future due to new research/tools/technology increases? The vast majority of hackers use commonly available tools to attack standardized routines. I would assume that fact would be the same in the future. So for some sake of some perceived purity today you are risking your data tomorrow from one very realistic possible avenue of attack. Even the best bcrypted stored hash from today is guaranteed to be crackable sometime in the future (if not already today by those much smarter than us with a lot more resources.) Do you think the securability of the stored hashes will always outlast the storage life of the backed up data? People are creatures of habit...which is why some of us enforce rules like not allowing users to reuse the same password from the last 6 utilized (and even then some really stubborn people change their password 7 times to get around that requirement.) Not many sites enforce such restrictions, so there shouldn't be any discount given to a password that is a few years old. For example, LinkedIn's breach is from 2012 and that password list is still being utilized by hackers today.
ReplyDeleteJeroen Wiert Pluimers it is not that easy to upgrade a password hash, the user notification process alone will be complicated (lost emails and all that jazz), some users will not want to do it without getting explanation (which they often cannot understand), so it can become very messy if you have a sizable user base.
ReplyDeleteFor instance Ashley Madison had upgraded from MD5 to bcrypt, but that left old passwords vulnerable:
http://cynosureprime.blogspot.fr/2015/09/how-we-cracked-millions-of-ashley.html
That said, I consider that any "Vanilla" security is in practice very weak, simply because weaknesses will be found in standards, and sooner or later they will not be patched or updated fast enough.. at which point the whole affair becomes vulnerable to automated hacking tools and bots.