A Quarter of Major CMSs Use Outdated MD5 as the Default Password Hashing Scheme (zdnet.com) 109
Over a quarter of all the major content management systems (CMSs) use the old and outdated MD5 hashing scheme as the default for securing and storing user passwords. From a report: Some of the projects that use MD5 as the default method for storing user passwords include WordPress, osCommerce, SuiteCRM, Simple Machines Forum, miniBB, MyBB, SugarCRM, CMS Made Simple, MantisBT, Phorum, Observium, X3cms, and Composr. The MD5 algorithm has been cracked for years now, meaning all passwords stored in this format can be reversed back to their plaintext version. This means that unless website owners changed these default settings by modifying the CMS source code, most websites built on top of these CMSs puts user passwords at risk in the case a hacker steals the site's database. This revelation is just one of the many observations that came out of an extensive academic research project at the University of Piraeus, in Greece. Academics examined 49 commonly used CMSs and 47 popular web application frameworks and looked at their default password storage mechanism, namely their password hashing schemes.
Most Enterprise solutions suck. (Score:2)
I normally Quiver when I hear CRM or Enterprise Solution, knowing I am going to be using some poorly designed software, which has been hobbled together over many years, with little to no long term architecture plan, but just a growth of the Bosses Nephew who knew how to code in VB 30 years ago.
While a Quarter uses MD5, I expected a half just has flat text stored in the database. then the last quarter a mix of Encrypted Password (where the Encryption keys security will be in states of questionably) and SHA (
Re: (Score:3)
When asked to make a new one, we undoubtedly get bosses who are looking at old ones and tell us that is the way to make it.
Boss: So what have you been working on for the last two weeks.
Me: Well I have been organizing the Database tables to handle the data elements, and making sure they are mapped and configured, so we can add additional fields in the future, while maintaining a good reporting data layout for ad-hoc reporting.
Boss: So you have nothing to show for yourself after two weeks, we need screen to s
Re: (Score:2)
but just a growth of the Bosses Nephew who knew how to code in VB 30 years ago.
That makes sense, since MD5 was outdated almost 30 years ago.
Re: (Score:3)
MD5 wasn't meant for creating secure passwords, it was designed to make sure data is accurate. Magnetic Tape, and old memory, had a much higher degree of failure, MD5 was a fast algorithm to insure the data that was loaded matched the data that was saved. 30 years ago being that most passwords were stored in flat text, saving them as MD5 allowed for a quick match to validate that the password match without actually showing the password. It seemed secure at the time, because technically MD5 cannot be rever
Re: Most Enterprise solutions suck. (Score:2)
No. MD5 was, as its initials show, was a message digest function. It was intended to be used as part of a digital signature scheme.
It had nothing to do with backup tapes. Thatâ(TM)s what CRCs were for. Sure, you can use MD5 to check the integrity of a tapeâ(TM)s data. But, collisions are, likely ok.
When using it in a signature algorithm, you want to ensure that forgeries are not easily computed - itâ(TM)s called non-repudiation. Cracking the digest and figuring out how to force collisio
Re: (Score:2)
MD5 wasn't meant for creating secure passwords, it was designed to make sure data is accurate.
MD5 is a cryptographic hash function created as a replacement for MD4 due to suspected cryptographic weaknesses.
Magnetic Tape, and old memory, had a much higher degree of failure, MD5 was a fast algorithm to insure the data that was loaded matched the data that was saved.
Cryptographic hash functions are neither required or ideal for detecting innocent sources of error.
Re: (Score:2)
There is the fact that serious security comes at a price, and marketing wants devs making new whiz-bang features to keep the CRM company in Gartner's Magic Quadrant, so security gets shuffled to the side with "security has no ROI" as the reason.
Then when the CRM program gets breached, the company can then mark the security hole as FNR (fixed in next release), and charge their customers an upgrade fee for version x+1 which might actually address the issue (like going from plain text passwords to crypt(3) or
Dedicated hardware wall (Score:2)
I've ranted about this many times, and never get a decent answer. I don't understand why passwords are not stored in a seperate device that has one and only job: storing the passwords. It would throttle login attempts so that nobody could try a username(s) a million times. You have a primary and a backup device that's kept in sync, and they could only be opened with a physical key and pin number.
The current standards will also be hacked if one allows kajillion attempts. The industry is doing it wrong, fight
Re: (Score:2)
You just described a TPM device.
The IT industry fought for years to keep them out of machines, they are now present in basically every machine, and hardly anything ever uses them.
Except, say, the iPad which stores encryption keys in them, encoded by the user's passcode/word/fingerprint.
Re: (Score:3)
Re: (Score:2)
The TPM is also hardware tamper-resistant and tamper-evident, so it makes it harder to physically extract data (keys, passwords, etc) and it's very clear if someone attempts to do so. A separate server doesn't have those qualities normally and if it did the cost would increase exponentially.
So
Re: (Score:3)
The TPM is also hardware tamper-resistant and tamper-evident, so it makes it harder to physically extract data (keys, passwords, etc) and it's very clear if someone attempts to do so
A separate server doesn't have those qualities normally and if it did the cost would increase exponentially.
So ... why not the TPM? This is literally what it was designed for.
This is a very easy question to answer.
1. TPM hardware is not designed to prevent exploitation of side channel attacks from those with physical access.
2. Most importantly TPM operations are not applicable to full lifecycle of protected credentials. A persistent compromise of application server would allow credentials to be stolen during initial onboarding and even as passwords are replaced due to lack of direct trust relationship between end users and itself.
If instead a separate computer system was used t
Re: (Score:2)
If instead a separate computer system was used to manage authentication then system can be designed in such a way ALL key management operations throughout the entire lifecycle of the secure data are completely independent of the application server.
You're asking way too much of these poor CMS admins. Most of them need help tying their shoes.
Re: (Score:2)
It's called bcrypt
https://www.php.net/manual/en/function.password-hash.php
Here's usage:
public function verifyPassword($password)
{
if(password_verify($password,$this->PasswordHash)) {
if (password_needs_rehash($this->PasswordHash,
Re: (Score:2)
You don't need two separate devices to limit the number of login attempts in a given time period.
A lot of CMS have the "after x failed attempts, temp ban the IP address for z minutes" setting.
Carrier-grade network address translation (Score:2)
A lot of CMS have the "after x failed attempts, temp ban the IP address for z minutes" setting.
Congratulations. You've just let one bad actor DoS other subscribers in the same city.
North America and Western Europe have a disproportionately large share of IPv4 addresses per person. Many ISPs outside these areas have ended up having to resort to carrier-grade network address translation (CGNAT) [wikipedia.org], which puts entire neighborhoods or even entire cities behind a single IPv4 address. Compare the case when Wikipedia blocked all of Qatar from editing [slashdot.org] for half a day back in January 2007.
Re: (Score:1)
Oftentimes the hacker gains access to the password file through some other hole not related to logins. Once they have that, they can pound away at a copy in their own basement for months (or via a zombie network).
Re: (Score:2)
Re: (Score:2)
You think that's bad? I don't even have a driving license!
Re: (Score:2)
If youre storing passwords ANYWHERE, youre doing it wrong.
In secure systems trust is always either assumed or contingent upon successful guarding of secrets. You can use cryptography to transform trust relationships to make securely managing trust easier and safer yet at the end of the day all transforms reduce to confidence in the integrity of a secret. It can be a secret stored in a safe deposit box, a TPM module, something remembered by a person or a physical key kept under armed guard. No matter its form a secret is being stored.
I personally don't think kee
Re: Dedicated hardware wall (Score:2)
If a user tries to log on to your site, how do you verify their credentials if you don't have them?
Re: (Score:1)
To clarify, I'm talking about storing hashed versions of the passwords, not raw passwords. It's still good to use encryption, but not allowing hackers to do mass retries and decryption tests still matters. A mote and a wall are better security than just a mote or just a wall.
Re: (Score:2)
There are devices which are similar, but there isn't anything out there that does this. TPMs and HSMs come to mind, but a dedicated HIDAM (hardware ID authentication module) is not something commercially available. However, it wouldn't be tough to design one. You could use a Web server interface and a REST query, with the username, password, and perhaps a third value, like the user's project. The HIDAM would take that info, return that the user is authenticated, the ID is invalid, or the account has bee
Re: (Score:1)
There's a nice startup idea for somebody eager for a shot at Big Time. Breaches are becoming more common; security is where to be.
Re: (Score:2)
The IETF is a volunteer-based group of folks employed by technology firms, universities, etc.
This is literally the worst kind of bullshit as you're telling people they need to understand things before commenting, while your basis is provably false on its face.
Source: University professor, initial designer of two ratified protocol RFCs, lead engineer at one of the most "Internet" involved companies.
Re: (Score:2)
That was a troll message pattern from a different site: https://fark.fandom.com/wiki/I... [fandom.com]
Re: (Score:2)
Simple: a) it is not necessary and b) it is not more secure. Of course also c) it does increase complexity and hence makes things _less_ secure and d) it raises cost for no good reason.
If you do this state-of-the art (Argon2 with good parameters), any guessing attack will fail (except for simple passwords) even if you have the database of hashed passwords. Very easy to guess passwords ("bob", "root") can just be guessed directly even with that separate hardware device. In fact, there is a bot-net that does
Re: (Score:2)
Noone tries a single username a million times, they try a single password a million times. On an organisation of any size, there will be at least one user with a weak password.
Re: Dedicated hardware wall (Score:2)
Congratulations, youâ(TM)ve described OAuth
Salt (Score:3)
Good luck reversing something like md5("UkA5tQVJ^ESCJj3t7B7$0Yl8u^dHRhx7"+salt). While it's true that md5 should be avoided for a variety of reasons, alarmism is hardly necessary.
People have been explained for years: pick a strong password, and don't reuse between sites. As long as people do that it's not useful to find a database full of md5'ed passwords. Of course, you are free to take your chances on a weaker password - or reusing it - it's just silly to put the responsibility for taking that chance on the website maker. If you don't wear a seatbelt you wouldn't blame the car maker would you? If you've got access to a CMS to the point that you have full access to the database you'd likely be capable of modifying the site to change it to simply forward you any entered passwords.
Re: (Score:1)
Good luck reversing something like md5("UkA5tQVJ^ESCJj3t7B7$0Yl8u^dHRhx7"+salt).
If you know the hash, it's not hard. Here's one website that will do it for you [sans.edu].
Re: (Score:2)
Ok, I generated the md5sum for you: CED87E262112135EB1C91C1695AD0A31
Now tell me what salt I used
Re: Salt (Score:2)
Re: (Score:2)
Re: (Score:2)
But the salt invalidate all reverse databases of MD5.
So what?
Re: (Score:3)
But the salt invalidate all reverse databases of MD5.
So what?
Read up what a "rainbow table" is and then come again. Seriously.
Re: (Score:2)
Read up what a "rainbow table" is and then come again. Seriously.
I assume everyone here knows what a rainbow table is. When I ask so what I'm asking what difference does it make?
Who cares if you use a rainbow table or run brute force from scratch without pre-computation? Do you think ultimate outcomes will be any meaningfully different? Do you believe user passwords are able to withstand brute force from scratch? If so "Seriously" applies. If not the question remains ... "So what?"
Transistors are too cheap, people have access to too many cheap cores across large net
Re: (Score:2)
A salt is an anti-rainbow table mechanism. It is effective. It eliminates the potentially huge speed- advantage a rainbow-table will give you when attacking multiple hashes at the same time.
Incidentally, brute-forcing good passwords stored with at least an iterated hash, but better with Argon2, will remain infeasible. Brute forcing very good password will remain infeasible even when they are stored with a single, unsalted MD5 hash. The reality is that this makes all the difference in the world when password
Re: (Score:2)
IIRC rainbow tables haven't been used in about five years because it's just as cheap to crack on the fly with GPU or ASICs as to store the tables.
Re: (Score:2)
The salt can be publicly announced if you like. It does not need to be kept secret at all. Same for the iteration count.
Re: (Score:2)
Keeping the salt private increases the cost of having the correct rainbow table. Few entities have all the rainbow tables for all the 8-byte salts, but the costs decrease every year.
Regardless the submitter should be banned for spreading FUD.
Re: (Score:2)
That's not how hashing works, as the input can be much larger than the output. You may be able to find something that hashes to the same value, but it doesn't work "backwards".
For example, both of these blocks have the same MD5: 0xf999c8c9 0xf7939ab6 0x84f3c481 0x1457cb23
0x6165300e,0x87a79a55,0xf7c60bd0,0x34febd0b,0x6503cf04,0x854f709e,0xfb0fc034,0x874c9c65,
0x2f94cc40,0x15a12deb,0x5c15f4a3,0x490786bb,0x6d658673,0xa4341f7d,0x8fd75920,0xefd18d5a
0x6165300e,0x87a79a55,0xf7c60bd0,0x34febd0b,0x6503cf04,0x854f749
Re: (Score:2)
I just tried with the md5sum of "hello" (although I may have included a \n at the end) and it didn't find it.
So it seems pretty useless as a web site.
Re: (Score:2)
Nonsense. This is a rainbow-table. It uses weak known passwords. It does not exploit any weakness in the hash used, it could be done the same for SHA512 (which is considered secure) easily. It cannot reverse a good passwords. It cannot reverse not-so-good salted and iterated passwords, with appropriate iteration counts. Actually, it cannot do it for an iteration count of 2 and no salt for MD5.
Actually, It tells me "Sorry, no solution found." and at the same time "Current "Hit Rate": 100 %", which does indic
Re: (Score:2)
I just tried that site and it could not find a match for "Monty Python". Not even "Monty " (with a space) produced a match. I had to dumb it down to just "Monty" for it to find a match.
So, just so you all know, "Monty Python" is a perfectly secure password.
Re: (Score:2)
Password length (entropy) is simple enough like a seat belt alarm to tell the user to provide more input. As for reuse, that only becomes a problem if sites fail to use unique salt. As for password weakness due to other factors (common words / combinations), again, the CMS should provide an alarm as to potential misuse ("it
Re: (Score:2)
BTW my technical opinion besides my reading
Re: (Score:2)
Actually, in this application, MD5 has no known vulnerabilities. There are just problems you also get if you use an unbroken crypto-hash.
That is not what it means (Score:5, Informative)
Re: (Score:1)
And unless there's been some new attack on MD5 I'm not aware of, it doesn't even mean that. It means that you can come up with two different passwords with the same hash, but given somebody else's hash, you still need a lot of brute force to construct a collision.
The real question is whether the hash is literally MD5 (a single round), for which 8 character passwords can be very easily brute-forced, or a MD5-based PBKDF (key derivation function) with a large number of rounds to make brute-forcing less practi
Re: (Score:2)
rainbow tables exist. if your database of md5 passwords is "obtained" in some way, its passwords might as well be ROT-26 encoded.
Rainbow tables have limited length and character coverage. They will reverse low entropy passwords while remaining completely worthless against high entropy ones.
Re: (Score:1)
If the passwords are properly salted, the value for that "collision" will be extremely unlikely to work with any other site that password/account may have been used with, so it's nothing like the old LinkedIn hack where people started getting emails with their password in it.
Re: (Score:2)
Indeed. So if you already have a password, you can create a second one. There is no need for that. It does not allow any additional attacks. While the password-storage schemes used may be insecure, use of MD5 is not the problem.
Federated login (Score:2)
I'd be curious if a significant number of deployed CMSs actually use some sort of federated login. I know when I've deployed Wordpress, the first thing I do is set it up to use our university's login system.
(the second thing I do is block access to everything under /wp-admin from off campus. Oh, and require ssl. This is turning into a Monty Python sketch...)
Re: (Score:2)
Have you ever tried going to /wp-admin/beware-of-the-leopard/ ?
It's hilarious.
MD5 hasn't been cracked for password storage (Score:5, Insightful)
MD5 is vulnerable to collision attacks, which is a big deal for signing, but not for password hashing.
In order to break password hashing, what you need is a preimage attack. And while there is a preimage attack on MD5, it is only theoretical (slower than bruteforce in practice).
I still wouldn't recommend MD5 but it is not as unsafe as it sounds. The real problems are :
- MD5 is really fast, which make brute force attacks easier
- The theoretical attacks may lead to practical ones in the future
- There are simply better options out there
But if for some reason, you really want to use MD5. With proper salting and key stretching, it is not that bad.
Re: (Score:2)
If you find a password hash collision and they aren't salting (possible given this software), you can use the input that produced the collision as the password and the auth software will let you right in because it will compare hash to hash.
You are confused. People are able to find MD5 collisions ONLY in cases the plaintext is known to them with a number of constraints on allowable modifications based on technique.
It's a completely different ball game when the source plaintext is NOT known. In this case there is currently no publicly available means of implementing any useful exploit.
Preimage (Score:2)
Finding a "collision" means finding two arbitrary strings with the same hash value. But if you already have a hash, you need to find another string whose hash value matches this hash value in particular. This string is called a "preimage" and is mathematically much harder to find than two arbitrary strings whose hash values match.
I'd bet even MD5 can be made reasonably secure within the PBKDF2 construction.
Re: (Score:2)
PBKDF2 is not really considered secure anymore. Please use Argon2. But if you use PBKDF2, using MD5 with is is not an issue. Iteration count and salt quality is.
Re: (Score:2)
Re: (Score:2)
Indeed. MD5 is not a problem here. If not salted and iterated, SHA512 is basically just as insecure. The whole complaint is clueless.
MD5 boogymen (Score:4, Informative)
What really pains me more than anything else is commentary like "The MD5 algorithm has been cracked for years now" I even see IETF drafts where people are trying to update HTTP digest authentication with new hash algorithms because MD5 is "broken".
A lot of people don't seem to have a grasp of basics and yet they are the same people commenting and implementing systems.
1. Upper entropy limits due to known preimage attacks on MD5 far exceed entropy of a password that anyone would use. MD5 has NOT been cracked.
2. Exponents protect one way passwords not multiplication factors even as impressive as those factors may seem.
So yes if you want to be stupid and do unsalted MD5 with no amplification your password database full of easy to guess passwords will get hacked in a few seconds time.
If on the other hand you use salts and amplification factors of 10000s the attacker will have to send off the password list to a botnet and wait hours to days for the same result.
In either case truly secure passwords with sufficient entropy to withstand a brute force campaign remain secure while passwords without sufficient entropy to stand on their own are cracked.
The lesson people should be taking away from this exercise is that storage of one way hashes as any kind of security mechanism is a BAD IDEA regardless of the hash algorithm selected or amplification scheme you chose. Expecting people to chose good enough passwords is a FOOLS ERRAND it won't happen no matter what you do.
It's much better to protect password databases with symmetric encryption key and even better to architect systems where authenticator is isolated from application servers such that compromise of application server cannot lead to compromise of password database.
Re: (Score:2)
A lot of the "MD5 is insecure!" crowd does no have a clue what exactly the insecurity is and where it matters and where it does not. All they can do is associated the terns "insecure" and "MD5". It is completely pathetic. Now, If they were complaining about a non-iterated and/or non-salted has being used to store passwords, that would make sense. If they were to complain that even a salted and iterated standard crypto-hash has no large-memory-property, that would be a valid complaint. (Use Argon2 to fix tha
Re: (Score:2)
You cant DECRYPT a hash back to cleartext, because there are lots of cleartext that has the same hash.
With passwords, you need to find only one ASCII string that has this hash. Each of these strings is called a preimage, and "decrypting" an MD5-hashed password means finding any of these preimages.
Not really surprised, considering (Score:1)
Four quarters (AFAIK) of major CMSs use outdated everything.
This is why I stick to (Score:2)
You've got other issues... (Score:1)
100% of the lists uses PHP (Score:2)
Choice of hashing algorithm not important.. (Score:2)
The key things would be if it is adequately salted and if enough rounds of PB-KDF are done, or similar.
MD5 as an HMAC and as the hash of a salted PB-KDF transform (the way you'd store a password) is fine, none of the known MD5 weaknesses both practical and theoretical matter to those applications.
If it is an unsalted single pass hash, then *all* the algorithms are terrible for any vaguely human friendly password.
Re: (Score:2)
Indeed. Better use Argon2 instead of any form of PBKDF2 though, PBKDF2 has no large memory property.
Why is "insecure" still the default? (Score:2)
If these things offer better security than MD5, why is it not the case that a brand new default install of any of these is not configured to use the most secure option.
Re: (Score:2)
Because in this use, the known weaknesses of MD5 do not matter.
MD5 is secure for this application (Score:2)
That is if it is used right. i.e. iterated and salted. And, just like any normal crypto-hash, it does not have a large memory property, hence you should use Argon2 instead. But the known weaknesses of MD5 are completely immaterial in this application. They basically allow you to guess an alternate password if you already have the right one. There is zero reason to do so and being able to do so does not compromise security.
The article is stupid and misinformed. MD5 is _not_ easy to reverse. That is _not_ the
Re: (Score:2)
Valerie Aurora called it [valerieaurora.org] in the first table: the Slashdotter reaction to a collision is to explain why it's no big deal, whereas people who are invested in having a secure system will have abandoned it before the collision is even found.
Windows (Score:2)
And 100% of windows devices still use NTLM to store user passwords, which is based on MD4!
And in most cases when signing up for a service hosted by someone else, you have no idea how they're going to store your password... A lot of banks these days require you to enter specific characters from your password which shows they're not storing it using a hashing algorithm.