Slashdot Mirror
Serious Crypto Bug Found In PHP 5.3.7
Trailrunner7 writes "The maintainers of the PHP scripting language are warning users about a serious crypto problem in the latest release and advising them not to upgrade to PHP 5.3.7 until the bug is resolved. PHP 5.3.7 was just released last week and that version contained fixes for a slew of security vulnerabilities. But now a serious flaw has been found in that new release that is related to the way that one of the cryptographic functions handles inputs. In some cases, when the crypt() function is called using MD5 salts, the function will return only the salt value."
Who cares about testing security code for regressions?
I'm seriously astounded that the php development community doesn't have acceptance testing around this sort of thing. In this day and age, why on earth is it the case that bugs like this get through?
http://gabrielcain.com/
Rut Roh raggy!
A collision attack exists that can find collisions within seconds on a computer with a 2.6Ghz Pentium4 processor (complexity of 2^24.1) Does salting garbage result in something edible?
Questions raise, answers kill. Raise questions to stay alive.
This bug has been fixed already. See https://bugs.php.net/bug.php?id=55439
Main problem was if an aplication stores its hashes in a database and use them as authentication then:
$valid = crypt($pw, $crypt);
will always be TRUE regardless of $pw
For all this, PHP Team said it is fixed in SVN and recomending to wait (upgrade) till 5.3.8
From that wikipedia article "The presented attack does not yet threaten practical applications of MD5".
A collision attack allows you find pairs of values that have the same MD5 hash, but these pairs are very rare.
This is a problem for digital signatures, since an attacker could create two files (one malicious one not) that both have the same signature. It's not a problem for passwords, since attackers can't control the password you pick.
.. if the code never calls the crypto. That is the case here.
The MD5 collision vulnerability only allows you to generate pairs of plaintext that share the same hash. It does not allow you to find a colliding plaintext-B from a given plaintext-A. It also does not allow you to compute a plaintext from a given hash.
In terms of passwords, here's what the exploit looks like: The attacker generates a pair of colliding texts; they use one of them as a password; the other text can also be used for the password. There are some contrived scenarios where this might be a problem, but for the normal case of authentication, it's a non-issue.
MD5 still needs to be dropped due to collisions, but passwords aren't the pressing reason.
The PHP project has shown some pretty poor QA when it comes to defects in their code.
Hell, their ODBC interface has been returning wrongly typed data for years now and nobody on the project seems to care. It's not like ODBC is something brand new and still widely misunderstood.
It's almost like the people who build PHP aren't even interested in maintaining it.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
Well, yes?
http://en.wikipedia.org/wiki/Salt_(cryptography)
Perhaps put very simply.. say you find a file full of e-mail addresses followed by md5 codes, e.g.
example@example.com 5eb63bbbe01eeed093cb22bb8f5acdc3
You deduce that they may be hashed login codes, so you run your MD5 hacking tool and find the password to be either "hello world" or "flurblgrabl".
You enter either "hello world" or "flurblgrabl", and you're in.
Now let's say you find instead:
example@example.com 5fc627d07b78d646f67411685c0591e8
You run your MD5 hacking tool and find the password to be a rather cryptic "hBd91qh0u1Zl13-12931" (it isn't, I can't be bothered getting an actual collision). Hey, must be somebody's strong password, right?
So you enter that as the password, and the site politely tells you to piss off.
So what went wrong? The site used a salt. I'll leave it to the clever chaps here to figure out the 'salt' used, but suffice to say that in practical applications the salt will be sufficiently complex to figure out (while ridiculously easy to implement; the simplest implementation simply adds a fixed set of characters to the password string) that finding collisions for the stored MD5 gets you nowhere.
Of course you might run into a problem where you allow the user - either by lack of recognizing the problem or due to a bug in verification code - to enter an empty password. In that case, at the very least with the simple implementations, the MD5 would be an MD5 of the salt itself.
Run an attack against that, take the results (potential salts), now run an attack against all the other MD5 signatures with the found potential salts tacked on until you get matching MD5s.
Now the correct salt has been identified, and the MD5s not just collided against, but completely identified. Now you can use that same information on other sites, and not have to worry about any salts they might use.
But you would still have to get pretty lucky.
Did you know that houses were the favoured target of burglars? Quick! Sell your house and buy a bungalow! Even though only 1% of houses are bungalows, they're attacked only 1% of the time if you consider all burglaries!
It's like saying "cars most likely target in car thefts".
Dickhead.
PHP has gotten itself into a vicious cycle where it inherently can't get better.
Anyone who knows what their doing will refuse to use PHP. That means that only the worst "programmers" out there will even consider it, let alone use it.
WIthout having good developers using it, it'll never have good developers contributing to it. No good developer would want to publicly admit that they've contributed to PHP.
At this point, some fool will throw out some crap like, "OmG but W1kip3D1A n faceb00K yooze PhP!@!#%@!!". None of that changes the fact that it's a horribly "designed" language, and it's just as poorly implemented. This single bug shows just how awful it is.
It seems the bug was filed before the release was made.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
MD5 should be deprecated, but the collision attack only invalidates signatures; it doesn't help you extract a password from its hash.
Currently there is no feasible non-dictionary attack for that (the preimage attack found in 2009 still has complexity >2^120), and the dictionary attacks are defeated by salt. So in this narrow context, yes.
(Of course, this would end if a somewhat more efficient preimage attack is found. 2^120 is orders of magnitude beyond usefulness, but not many orders...)
A bug in a library function shows how a language is poorly designed? Methinks you need a little more logical organization to your thoughts. and I can't help but laugh at "no good developer would want to publicly admit that they've contributed to PHP". Perhaps no good developer would want to admit to posting your comment, hence Anonymous Coward status.
Well, yes?
The problem with salting: transfer the matter into "security by obscurity".
If the repo of you passwords leaks, one can assume the salt grains would leak too. Then you are not better than having the hashed password alone to attack.
Questions raise, answers kill. Raise questions to stay alive.
Run an attack against that, take the results (potential salts), now run an attack against all the other MD5 signatures with the found potential salts tacked on until you get matching MD5s.
Now the correct salt has been identified
If you know what a salt is, you should also know that using the same salt for different accounts is very very bad.
The internal crypt() function of PHP is only there whenever the system function doesn't exist. So for example, in Debian, only the blowfish encryption is affected, all other encryption are using the system. Here's Ondrej post about it:
http://lists.alioth.debian.org/pipermail/pkg-php-maint/2011-August/009328.html
I am guessing that this will be the case in most Unix distribution, but it will be an issue on platforms like Windows. So, maybe this is just too much buzz...
What's fixed by using salt in your passwords is that the leaked password file can't be compared against a precomputed password dictionary.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
I've read that last paragraph 6 times and still don't understand what you are getting at. The attacker can't control what message you create any more than the password, so what is the difference?
Let me get this straight. You're accusing him of needing "more logical organization" in his thoughts, all while you're defending one of the worst programming languages ever to be created? And it's the message that matters, not who delivered it. You've missed the message by focusing solely on the messenger.
This bug never should have happened. There's absolutely no excuse for it. Even a shitty programmer would not have made this mistake. Seriously, go look at the diff of the fix. It's mind-boggling that it happened in the first place.
This kind of bug never happens in Java-based web frameworks, or .NET-based web frameworks, or Python-based web frameworks, or Ruby-based web frameworks, or Perl-based web frameworks. Nobody else screws up like this. But somehow PHP manages to do this constantly. Look at its changelogs, for crying out loud. It's one pathetic bug after another, year after year, even in their most stable releases. It clearly must be a problem with the PHP community, because nobody else is affected by this problem to the degree that PHP is. Not even Microsoft, I dare admit it!
Really, that's like saying "switch to Macs because Windows are the most attacked by hackers!". It's just because they're more popular. I guaran-dang-tee you that IIS servers aren't any safer than a LAMP stack.
Actually you can do that with MD5, it is called a chosen prefix/suffix attack. What you cannot do as far as I know is generate a preimage efficiently which is what is required to break a password hash.
Wow, someone stuck burning herring up your ass didn't they (Rhetorical, we all know they did)?
Your logic sticks as much as that herring.
Maybe I would like Java more if the people who owned it weren't so evil they make MS look good.
And if the people who choose to use it didnt use 5000 different addon libraries with confusing names that say nothing about what they hell they do (Spring, Struts, Hibernate etc etc etc)
MD5 should be deprecated, but the collision attack only invalidates signatures;
Because you are not "decrypting" the password, finding a collision will be an attack for passwords as well - fortunately, as others pointed out, it's currently still 2^120.
and the dictionary attacks are defeated by salt
I argue that using a "salting for passwords" it's useless (doesn't do harm, but doesn't bring in too much good either) . Unlike signatures/message digests, the checksum is not made public (the passwords - or their checksum - are stored in a "secure place") and the attacker usually has longer time for cracking a password - until you change it.
If the attacker got a checksum of a password, it means that the attacker broke your "secure place" - what warranties do you have that the attacker didn't get your salt as well?
Questions raise, answers kill. Raise questions to stay alive.
This isn't a problem for someone else making a new message from yours, but one where they make the message. Say a contract, given two different texts from the contract they could add some "garbage" data to them to make them have identical signatures. Now this attack would be a little far fetched, as soon as you can produce your copy of the message that hashes the same for the signature, you can prove something fishy is going on, just not what right away.
The problem with salting: transfer the matter into "security by obscurity".
Which is what passwords are in the first place, and, by extension, any mechanism of manipulating or digesting them.
If the repo of you passwords leaks, one can assume the salt grains would leak too. Then you are not better than having the hashed password alone to attack.
Password hashes are typically stored in a database. The salt is typically part of the configuration store. Most systems (Wordpress being the singular counterexample I can think of) store user data separate from configuration data, and configuration data is usually left flat files. (LDAP is an alternative, but I don't believe most services use it)
So even if the password hashes leak, it's unlikely the salt will leak.
tasks(723) drafts(105) languages(484) examples(29106)
You do realise the reason facebook and wikipedia use it is due to the rest of the web community also using it?
You do realise that PHP is tried, tested, and working in countless webservers around the world right?
You do realise that all languages have trade offs, bugs, weird shit, good parts, bad parts, bad developers, good developers and people that make do with a widely accepted language regardless of how "bad" it is?
You do realise that "bad" is an entirely relative term and just maybe not everyone in the world thinks a bad language is necessarily worse than another for business goals?
You do realise that nobody in the real world gives a shit about people like you that can't even see the fact that making release, making sales and maximizing profits is more important that your geek status with your dumb ass friends at starbucks and your two bit freelance websites that use "web2.0", "the cloud" and ajax to show a companies "about us" page and "contact us" form?
I'd ask but I know you don't realise how stupid you look.
Here is a good write-up of the bug:
http://pwnhome.wordpress.com/2011/08/22/php-crypt-bug/
Typically, salt and hash are stored together as one string, and each password will have its own randomly selected salt.
Salting is for defending against precomputed dictionary attacks. You're not supposed to keep the salt secret.
I just had to have a very similar situation for a web site that I wanted, I went out for bids, and got about 5 solid coders, each one real good, each had a quote price with in 4500 of each other, all different languages it all came down to delivery date.
I took the PHP guy, why, real simple, he said to me, prototype web site in Photoshop in 3 days, working web site idea in a week, beta test on the 14th day, can go live within another week and afterwards with 3 months of support, bug cleaning, and code clean up free. bottom line he said, if it works you'll hire me on the 4th month for years, and then we can recode it in whatever you want.
the truth of the matter seems that i wanted a delivery date that could be hit, Who knows I might have done something wrong but first to market always get's the attention.
if you see me, smile and say hello.
I've seen a few people here note the fact that "salts" are used to add complexity to a password where no complexity exists. I believe this is incorrect, or at the very least not entirely the truth.
/dev/urandom (VPS machine...) and then MD5 that to get a usable salt, then use CRYPT() with its default of 5000 rounds to hash the password via SHA512.
Many are assuming that the salt is something that wouldn't be compromised, i.e.
$SITE_SALT = 'LULZYOUCANTGUESSTHIS';
$HASH = MD5($SITE_SALT + $PASSWORD);
I think this is a bit of a misunderstanding. The salt is not necessarily intended to be a secret value unless you can ensure the security of that value, that is the salt is never revealed unless fully guarded (you have a hidden, ultra secure password hashing mechanism that keeps the salt out of the hands of the system).
In this case, I use mcrypt_create_iv() to generate from
In this case, the salt generation prevents the generation of usable rainbow tables. This does not stop dictionary attacks, but the added rounds of hashing increases the complexity for brute force attacks.
TLDR: ENFORCE PASSWORD COMPLEXITY, USE ENCRYPTION OR MANY ROUNDS OF HASHING, AND USE A UNIQUE SALT PER PASSWORD.
That's not how I've generally seen salts used. Generally, I've seen salts used like "echo $SALT$DATA|md5sum".
I'm not disputing that the method you describe isn't done, I just haven't seen it done that way.
tasks(723) drafts(105) languages(484) examples(29106)
You should be salting each password with a unique salt - and storing the salt with the hash!
The reason for salting the password is to invalidate rainbow tables by effectively making the hashing function unique for each password.
Yes it's a problem for an attacker to get your hashes, but if they do you have made sure they have to break each and every password separately rather than the whole lot at once. Or even worse having precomputed MD5 tables being able to break them immediately.
What you're missing is that even if they have both the hash/checksum and the salt, they then have to start bruteforcing the password from scratch. Because they didn't know the salt in advance, they couldn't have precomputed a dictionary of hash -> password mappings like you can with unsalted passwords, so each password has to be bruteforced separately. If the passwords aren't salted, and are just plain md5 (say), it's entirely possible that they already know what the md5 reverse-maps to because they've seen it before; it only takes a quick Google to determine that 5eb63bbbe01eeed093cb22bb8f5acdc3 is the md5 hash of "hello world", for instance, whereas if it were salted you'd have to try possibilities from scratch until you guessed that the input was "hello world" (it's kind-of guessable, but it likely wouldn't be near the top of your dictionary, so it'd take a while of brute-forcing to hit it). So, a salt is useful even if it's stored with your password file.
As another issue, if you don't salt your passwords, merely by comparing hashes you can tell that two users have the same password from a list of hashes. This also means that you could register an account on the site with a common password like "password" and instantly see who else was using it, giving you a load of accounts to quickly compromise...
(1)DOCOMEFROM!2~.2'~#1WHILE:1<-"'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$"'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
I just had a fun idea, but it requires knowing the salt that will be used, and it doesn't actually have any practical value:
1. Learn which salt will be used.
2. Generate a pair of collisions, such that: md5(salt + A) == md5(salt + B)
3. Register using password A.
4. Sign in using password B.
Amaze your friends; you now have two, Two, TWO passwords! Ah. Ah. Ah.
Unit tests are slow and they almost always pass.
That's why they make big ass clusters out of big ass multicore computers. Run a test on each core. Beowulf would be proud.
For passwords it's more like: echo "MD5${SALT}"`echo -n "${SALT}${DATA}"|md5sum`
where ${SALT} is random and unique to the user.
Everyone should be using mysql_real_crypt by now.
Dewey, what part of this looks like authorities should be involved?
I wonder if PHP has the same problem we do in Hadoop-land... the lack of enough qualified security people interested enough in a project to actually review code. For example, I'd love for someone with a clue to review Alfredo ( http://cloudera.github.com/alfredo/docs/latest/index.html ) before we build a dependency on it ( https://issues.apache.org/jira/browse/HADOOP-7119 ) . But it seems as though getting the right people involved is extremely difficult. :(
I think that the post you replied to was a bit extreme, but it's not the bug in the library function that caused him to say that: it's the fact that the PHP project lacks the testing infrastructure that any reasonable project of that size would have.
Anyone can commit a bug; that's easy and excusable. What makes it look like PHP is developed by a bunch of 12 year olds is the fact that they have a test suite with a test that exhibited the bug, and yet no one ran it before they made a release, because they've got too many failing tests so it just got swamped in with that noise.
I'm working on some dinky pieces of research software, and while we probably don't have as extensive a test suite as PHP does, we have a way better testing regimen. A project like PHP should have a CI server that runs their tests at least nightly, and a release shouldn't be made while there are failing tests. That's what expected failures are for. (They even know about expected failures, but still have over 200 failing tests for some reason.) Even we've got that.
It's the QA that's messed up, not the coding.
Of course an attacker who steals your password database knows the salt values in use for each account.
But unless they have a rainbow table calculated with every possible salt value taken into account, they can't do a simple lookup on a precomputed map of hash values to top-5,000,000-common-passwords and hope to get a match... so their expense to actually break any of those passwords is much, much higher.
it's not the bug in the library function that caused him to say that
OK, reading the thread again I may be projecting. But that's my take on the situation anyway.
You are laughing at PHP, while grouping .net and java based stuff in the "serious business" category?
Java and everything .net related are the biggest jokes ever in the history of computing.
PHP is a simple language that is robust enough to build complex applications. Sure, it's grown organically, and you can see that in its current design, and yes, a bug escapes here and there, but it's unfair to compare it to Perl. For instance, Perl has been stable for 20 years. PHP was totally rewritten in PHP3, and went through yet another major change for version 4. Version 5 is the first real stable release that has most of the features one could expect in a mature, modern language.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
No, it actually was a bug in the way the function was called, not the library itself - see comment number four: https://plus.google.com/113641248237520845183/posts/g68d9RvRA1i
In reality, almost nobody* is going to call md5 via crypt() when a standalone md5() function exists, and people are often slow to deploy new versions of PHP - especially major shared hosting providers. Those who manage their own PHP installs and deploy shortly after release tend to have their own set of unit tests, which very likely would have caught this if their own code was affected (Hmm, I can't login anymore. Suddenly my password hash is only twelve characters long? That's not right...)
Of course, if you hit all of the worst cases and push this out, yeah, pretty serious problem.
* Yes, I've seen exceptions to that. Some weird AWS message signing comes to mind, IIRC. Hence "almost".
How are sites slashdotted when nobody reads TFAs?
finding a collision
it's not a "collision", it's a "preimage". these are technical terms with specific meanings.
False.
Unless there happens to be a pre-computed rainbow table that includes the salt of the password (likelihood: practically zero), you are still massively better off. In that case, you'll have to generate your own rainbow tables if there's a single salt for all entries, or go cry yourself into a corner in the hopefully more likely scenario where each entry has its own unique salt (because you now need to bang out a rainbow table for every entry in the users table).
Nearly all security is based on obscurity (you don't know my password; that's obscure information), so the more obscurity the better. It just happens that port 8080 is a lot less secure than "$0m3 s[]{}per séc®e7 p4sS\/\/0rd", so that better not be your only line of defense.
How are sites slashdotted when nobody reads TFAs?
Steve, I know you're pretty animated on stage, but it's just not the same when you're only using boldface and caps.
Does having a witty signature really indicate normality?
Read up on the difference between Collision attack and Preimage attack.
MD5 is vulnerable to collision, but not yet preimage attacks. The preimage attack the GP is mentioning is something like this: Alice is required to digitally sign off on all money withdrawals from an account, and MD5 is used as a hash algorithm. Bob creates two documents, one saying "I authorize the withdrawal of $100." and another saying "I authorize the withdrawal of $1,000,000." He uses a collision attack to ensure that these two documents both hash to the same MD5 value. He then gives Alice the $100 note to sign. She does so creating a digital signature, which happens to also be valid for the $1,000,000 note (unbeknownst to her). Bob then submits the $1,000,000 request for withdrawal, along with a valid signature from Alice.
In general, it is Very Bad if two documents can be created with the same hash. But yes, not going to help cracking passwords though.
If the repo of you passwords leaks, one can assume the salt grains would leak too.
Current best practices (as defined by what Zend "The PHP Company" recommends, which is relevant here) is a combination of static and dynamic hash. Static is hard coded to your application and won't be compromised unless the whole codebase is compromised. Dynamic hashes are stored to the DB and are different for each user. If just the DB is compromised, attackers won't know the (static part of) salt. If both the DB and the application code are compromised you're obviously fucked in any case but even then it's very slow to find out all the passwords as you need to attack each user separately due to each having different (dynamic) salt.
Oh, and not only is the project's QA apparently nonexistent (not that they're the only big project that doesn't have useful tests), they also don't have any sense when it comes to their website. OK, they posted a message that 5.3.7 has a severe security bug on their front page; that's a good start.
But they then should have pulled the release, and made it deliberately difficult to get to. They didn't. If you Google "PHP", the second link is to their download page, and you can grab 5.3.7 from there without ever seeing that warning.
I'm pretty sure that the project is run by a bunch of 12 year olds.
I know there's no reason a skilled programmer can't use php, but in my experience the users that request php access are generally the users who you'd least want to have any sort of script-level access to your servers. When I've explained to requestors why we don't generally provide php, I've been told on several occasions "I don't want or need the ability to run scripts! I just want to create php web pages." Oh, and mysql access requests usually come hand-in-hand with php requests.
I remember one guy, quite a few years ago, who asked us to 1) enable php on our department's web server; and 2) give him access to create and run php scripts. To demonstrate to us that he wasn't just another newbie... he wrote a php script and placed it on his own personal box as a demo of his coding skill. This script let anyone, anywhere, examine the content of any file in the /etc/ directory via an easy to use web interface.
We politely declined his request.
#DeleteChrome
Yup. The problem here seems to be with procedures rather than technology. Bugs happen. What matters is what you do when a bug happens. The bug was reported before release date and the bug should have been marked as a showstopper.
PHP 5.3.7 should not have been released with a known bug of such magnitude. It's an open source project without commercial interrests; it doesn't matter if a release is delayerd for a couple of days.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Yes, that's how the salt is applied, but then it has to be stored, and Goaway is correct that the usual approach is
HASH=`echo -n $SALT$DATA | md5sum`
STORED_VALUE=$SALT:$HASH
Of course, the *better* approach is to use bcrypt rather than md5 and to store your bcrypt parameters in the string too.
You're kidding yourself. JAVA and .NET are platforms suitable for enterprise environments, while PHP isn't. You're right that php is simple language, but it's also suitable for writing only simplest applications.
Here's 3 NOPs - come back when you're doing real programming.
Also, your reverse function is terrible, use indexes.
In reality, almost nobody* is going to call md5 via crypt() when a standalone md5() function exists
Yes they are, because the two don't do the same thing. md5 just calculates the md5 of data, whereas the md5 support of crypt uses salting and a large number of rounds to make password cracking harder.
Yep - but sadly commonplace.
-sigh-
What you have here (in crypt) is the PHK MD5 crypt() algorithm. This isn't just "let's run MD5 over a string" or even "run MD5 over a string and some salt".
PHK's design (and all algorithms in crypt) has both the following features
1. Multiple iterations. The hash isn't just run once, it's iterated so you have a hash of a hash and so on for many levels. This makes executing crypt() for user logins slow. It thus makes brute force attacks, online or offline far more expensive than they would otherwise be to the point where they're non-viable for decent passwords
2. Salt. Salt is not a "secret" as one poster seems to think. Instead salt just makes pre-computation (e.g. dictionary attack or rainbow table) worthless. If you understand what a "rainbow table" is you can think of salt as forcing the bad guys to generate a separate rainbow table for each salt value they care about. But generating a rainbow table is only worthwhile if you're going to use the same one hundreds of times or more. With so many possible salt values this'll never happen, so it's pointless and you must resort to brute force, but see above.
The most modern crypt() routines add a third feature
3. Variable iterations. As CPUs get more powerful you can wind up the number of iterations to keep it just cheap enough to be affordable for you to verify correct logins, while far too expensive for bad guys to attack.
The collision attack is completely irrelevant to PHK MD5, digest collision attacks would let you tell person A a password and person B a different (but probably very long and difficult to type) password and have them both work. It's not clear what possible purpose this trick would have, and it certainly doesn't help you to figure out person C's password from its hash.
It still can, salt just makes it impractical. Of course if you had a true Turing machine even salt would be useless, but alas nobody as of yet has come up with an infinite storage device.
Monstar L
unix crypt(3)... you must be too young to remember rainbow tables
It's misshapen, blotchy and has bits of shit sticking to it?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I don't think they should have pulled it, if you don't use the the crypt() function the other fixes and features of the upgrade may well make it a worthwhile upgrade. However I agree that the download page should be marked with this information, not just the front page.
No, but releasing an update without even running the existing unit tests shows how amateurish the whole PHP project is. The terrible design of the language is also a reflection of its amateurish nature.
It's true that some websites manage to do wonderful things with PHP, but then it's also true that some artists manage to make wonderful sculptures out of manure. That doesn't mean it's a good choice for most people.
LOL! Thanks for the laugh, bud. Jokers like you are the reason I read Slashdot.
I'll tell my boss that we need to get to work re-writing 90% of what our department has done in the last 5 years as quickly as possible in java. PHP can do anything I need it to do, as besides the occasional security bugs (and this one doesn't seem to effect me), it works great.
It's the programmer that makes the program, not the language.
Collision attacks are no threat to passwords. They are a threat to things like certificate signatures when the certificate is made by the attacker.
Please do not post nonsense.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Don't worry, the OSGi people are going to fix the confusing name mess. Pretty soon, those libraries will be OSGi Spring or Struts OSGi or HibernateBeanOSGi.
But first they need to figure out what OSGi stands for. Or even what it does. (They know it doubles as a sandwich spread and a floor cleaner, and there are a lot of buzzwords involved, but are not quite clear beyond that.)
It's the programmer that makes the program, not the language.
If only I had some mod points for you, but alas you'll have to settle for a measly symbolic +1. Oh, alright - here's a 3 as well.
I remember rainbow tables...and I remember that salting was the counter to them.
tasks(723) drafts(105) languages(484) examples(29106)
I disagree. Is there really some super-pressing feature that you can't wait a couple more days for .8? And what if you don't call crypt(), but some library you're using does? Are you that familiar with all of your code base? And what about in the future? What if in 6 months you decide to use crypt(), are you going to remember about this bug? (Hopefully you'd notice that your logins are always successful.)
I'm not necessarily saying it should be totally unavailable, but I don't think it should be particularly easy to get to.
(Or maybe I would consider replacing the download with one that unzips to a couple additional higher level directories: this_release_has_a_buggy_crypt/read_security.txt_first/.)
Having worked with ASP.NET and Java + Wicket (WebSphere, you bastard), I still prefer working with PHP - there's just something about "doing it yourself" that feels just right.
Trying to simple things in ASP.NET and Java seems so awkward. Trying to create a self-processing page in these languages requires so much extra effort, for something that should be so simple...
But that's just my observation while trying them out. I'd take programming in PHP over any other language any day - but perhaps its just because I'm that much more familiar with it (and prefer the more low-level that it seems to be compared to having to instantiate tons of different classes just to do something simple like set a session or cookie)...
Indeed. I remember running some WWWBoards back in the '90s, and even those salted the password. I believe they just grabbed a particular substring of each password and fed it as the salt into the crypt function, so you had a (more or less) unique salt for every password. And that was a simple perl script from the '90s. I would hope everyone is doing at least a little more than that today.
Check out my world simulator thingy.
"All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.7."
None of that changes the fact that it's a horribly "designed" language
It was "designed"??? Whoa...I think I just experienced a negative reality inversion.
No sig today...
We all know "real FORTRAN programmers can write FORTRAN in any language" but when fresh young minds are exposed to programming I don't think PHP is an ideal choice. When (eg.) strings can be compared with numbers without so much as a warning you know there's a WTF brewing.
No sig today...
The problem with salting: transfer the matter into "security by obscurity".
The only point of per-site (and ideally per-user) salt is so that a pre-computed rainbow table attack does not work. And salt is a semi-public piece of information. It has to be published in enough places through your code that you must assume that the attacker knows how you salt. And often, the salt is stored right along side the password in the password hash.
Without salt: attackers create the huge rainbow table of about a billion passwords and their resulting has values. They then obtain your password hashes. Now they can simply look up the hash value, find it in their massive pre-computed rainbow table and use the corresponding password to login to your site.
Use once - exploit everywhere.
So, you say, let's use a unique salt for our entire site. Now the attacker's precomputed rainbow table is rendered useless. Now they will either create a new rainbow table (which is a lot of work) or start brute forcing against your password hashes (as salt values *have* to be semi-public in order for them to work). The attack takes longer, but if they do find a password, because you used per-site salts, they can instantly scan the list of the other hashes on your site to see whether any other accounts use that exact same password hash.
Now you have (1) broken account which allowed them to instantly crack any other account that happened to use the same password.
Right - now we do per-user salt (which is the proper way). Rainbow attacks no longer work. And the weakness in one account's password does not automatically expose other accounts that also use the same password. Every account has to be individually brute-forced, which slows the attacker down a lot if you enforce some form of password complexity.
Wolde you bothe eate your cake, and have your cake?
I'm sad to see this first dent in PHP's hithertofore untarnished reputation for impenetrable security. Up to now, PHP has been widely perceived as a touchstone of security; the penultimate platform upon which the most secure web sites are based. Truly, this will come as terrible news to all those who have come to depend on PHP's unrelenting security. I guess it just goes to show that toilet paper will eventually yield to the incessant battering of the moth, no matter how many plys it is constructed of.
My mortgage broker let me sit down
Mortgage north face sale money tight. First-time home buyers plan, the future of the market, the lowest ten percent lower. I was raised that the family is an investment.My mortgage broker let me sit down
Mortgage north face sale money tight. First-time home buyers plan, the future of the market, the lowest ten percent lower. I was raised that the family is an investment.My mortgage broker let me sit down
Mortgage north face sale money tight. First-time home buyers plan, the future of the market, the lowest ten percent lower. I was raised that the family is an investment.My mortgage broker let me sit down
Mortgage north face sale money tight. First-time home buyers plan, the future of the market, the lowest ten percent lower. I was raised that the family is an investment.My mortgage broker let me sit down
Mortgage north face sale money tight. First-time home buyers plan, the future of the market, the lowest ten percent lower. I was raised that the family is an investment.
Words fail me, I hope that comment isn't true (I'll have a go at running the 5.3.7 test suite myself at some point) but if it is then that is unbelievable. Nothing and I mean NOTHING should be getting integrated into the main branch if the tests are failing - nevermind an actual release!
So what if you can compare strings and numbers? I see that as a plus.
Ah, so the only person that can really take advantage of it would be the person creating the legitimate one as well. It kind of sounded from the original that the attack could be used to impersonate someone. Thanks for clarifying.
Hmm, when you say "take advantage of it" are you talking about the well-known MD5 collision attack, or the PHP crypt bug?
Re the collision attack: I think you are right. But still, advice going around is "don't use MD5". Researchers are still chipping away at it, so there's no telling when they'll have a working preimage attack.
Re the PHP crypt bug: my understanding is that it's quite serious in that it can throw away the input and just use the salt, causing widespread MD5 collisions. So that could definitely be used to impersonate someone. The former is a slight cryptographic weakness, the latter is a serious bug.
News at 11.
Amaze your friends; you now have two, Two, TWO passwords! Ah. Ah. Ah.
Why not go a bit further? There are infinite number of inputs for a hash function that produce the same output.