Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Serious Crypto Bug Found In PHP 5.3.7

timothy posted more than 2 years ago | from the pronounced-pfffffpp dept.

PHP 165

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."

cancel ×

165 comments

Sorry! There are no comments related to the filter you selected.

Regression tests are for wimps! (5, Insightful)

Niac (2101) | more than 2 years ago | (#37173218)

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?

Re:Regression tests are for wimps! (3, Funny)

PCM2 (4486) | more than 2 years ago | (#37173234)

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?

Speaking as an occasional PHP developer, you must be new here.

Re:Regression tests are for wimps! (1)

Niac (2101) | more than 2 years ago | (#37173282)

Okay, fair point. I try to give PHP the benefit of the doubt... ;) I'd like to think that they've got automated testing of submitted code. I'd like to... :-(

Re:Regression tests are for wimps! (0)

Anonymous Coward | more than 2 years ago | (#37173290)

They do have unit tests, they didn't run the bloody things.

Re:Regression tests are for wimps! (4, Insightful)

rainmayun (842754) | more than 2 years ago | (#37173294)

True, PHP has a history of "winging it", but by now they should be doing a pretty damn extensive suite of regression tests against each release candidate, if not each build. At this point in its life and supposed maturity, the PHP Group should really be doing better.

PHP can't get better. It drives away anyone good. (2, Insightful)

Anonymous Coward | more than 2 years ago | (#37173496)

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.

Re:PHP can't get better. It drives away anyone goo (2)

rainmayun (842754) | more than 2 years ago | (#37173570)

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.

Re:PHP can't get better. It drives away anyone goo (0, Flamebait)

Anonymous Coward | more than 2 years ago | (#37173682)

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!

Re:PHP can't get better. It drives away anyone goo (1)

GNUALMAFUERTE (697061) | more than 2 years ago | (#37174444)

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.

Re:PHP can't get better. It drives away anyone goo (0)

Anonymous Coward | more than 2 years ago | (#37175508)

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.

Re:PHP can't get better. It drives away anyone goo (5, Insightful)

EvanED (569694) | more than 2 years ago | (#37174390)

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.

Re:PHP can't get better. It drives away anyone goo (1)

EvanED (569694) | more than 2 years ago | (#37174428)

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.

Re:PHP can't get better. It drives away anyone goo (1)

EvanED (569694) | more than 2 years ago | (#37175012)

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 [php.net] , 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.

Re:PHP can't get better. It drives away anyone goo (1)

mwvdlee (775178) | more than 2 years ago | (#37175466)

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.

Re:PHP can't get better. It drives away anyone goo (1)

Firehed (942385) | more than 2 years ago | (#37174450)

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 [google.com]

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".

Re:PHP can't get better. It drives away anyone goo (2)

makomk (752139) | more than 2 years ago | (#37175740)

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.

Re:PHP can't get better. It drives away anyone goo (0)

Anonymous Coward | more than 2 years ago | (#37173740)

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.

Re:PHP can't get better. It drives away anyone goo (0)

Anonymous Coward | more than 2 years ago | (#37173934)

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.

Re:PHP can't get better. It drives away anyone goo (-1)

Anonymous Coward | more than 2 years ago | (#37174024)

Your defense of PHP has proven his point perfectly. Only idiots use it.

Re:PHP can't get better. It drives away anyone goo (2)

onepoint (301486) | more than 2 years ago | (#37174106)

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.

Re:PHP can't get better. It drives away anyone goo (0)

Anonymous Coward | more than 2 years ago | (#37175680)

Here's 3 NOPs - come back when you're doing real programming.

Re:Regression tests are for wimps! (0)

Anonymous Coward | more than 2 years ago | (#37173274)

was it a regression?

Re:Regression tests are for wimps! (1)

Anonymous Coward | more than 2 years ago | (#37174192)

Looking at the actual bug report [php.net] , yes, I'd say so. Returning the salt without the hash does rather defeat the point of hashing.

Re:Regression tests are for wimps! (4, Informative)

thue (121682) | more than 2 years ago | (#37173332)

From the Bug report [php.net] :

> Confirming, some very recent update broke it - right now unit tests fail on SVN. I wonder if nobody run it before release?

So they do have a unit test for that. They just didn't run it before release :).

Re:Regression tests are for wimps! (4, Insightful)

Arancaytar (966377) | more than 2 years ago | (#37173370)

Unit tests are slow and they almost always pass. When you're in a rush to release, sometimes you feel lucky.
Of course, you're not. That's the whole point of unit tests...

Re:Regression tests are for wimps! (1)

Anonymous Coward | more than 2 years ago | (#37173678)

If you're rushing to release, you've already failed. Best not to make more mistakes.

Re:Regression tests are for wimps! (2)

Chuck Chunder (21021) | more than 2 years ago | (#37173812)

It seems [php.net] that the bug was in the code base for at ~10 days before someone (external) discovered it. That does not seem to be (just) a case of unit tests being skipped in a rush, it seems like a surprising lack of automated testing.

Imagine a Beowulf cluster of test boxes (1)

tepples (727027) | more than 2 years ago | (#37174300)

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 [wikipedia.org] would be proud.

Re:Regression tests are for wimps! (0)

Anonymous Coward | more than 2 years ago | (#37174756)

Every time I have run 'make test' on PHP (at least 10 times over various releases) it has always failed a number of tests.

Re:Regression tests are for wimps! (0)

Anonymous Coward | more than 2 years ago | (#37175306)

You're doing it wrong.

Not only that (3, Informative)

Chuck Chunder (21021) | more than 2 years ago | (#37173506)

It seems the bug was filed before the release was made.

Re:Regression tests are for wimps! (1)

mgiuca (1040724) | more than 2 years ago | (#37174574)

Sounds like they need Retaliation [slashdot.org] !

Re:Regression tests are for wimps! (2, Informative)

msauve (701917) | more than 2 years ago | (#37173450)

"I'm seriously astounded that the php development community doesn't have acceptance testing around this sort of thing."

Two things.

1) The problem was found and announced by "the php development community," and presumably found by them, too (admittedly, not prior to release).
2) Why aren't you involved in acceptance testing, if you see a problem with how it's being done?

Re:Regression tests are for wimps! (1)

Korin43 (881732) | more than 2 years ago | (#37173742)

2) Because it's PHP. No one wants to be involved with that.

Re:Regression tests are for wimps! (0)

Anonymous Coward | more than 2 years ago | (#37174180)

2) So don't use it. What's the problem?

Re:Regression tests are for wimps! (1)

Niac (2101) | more than 2 years ago | (#37174210)

Pretty much. Also, I'm not a dev. I do other things, and only support PHP apps, rather than developing them.

Bottom line? I prefer to spend my time elsewhere.

Re:Regression tests are for wimps! (0)

Anonymous Coward | more than 2 years ago | (#37173858)

What kind of logic is that? You don't need to butt-fuck every twink in the country to know that's AIDS is an avoidable disease.

Re:Regression tests are for wimps! (4, Informative)

Chuck Chunder (21021) | more than 2 years ago | (#37174378)

1) The problem was found and announced by "the php development community," and presumably found by them, too (admittedly, not prior to release).

That seems entirely incorrect. According to the bug report [php.net] it seems to have been found by someone external, it was found in a release candidate not the released version and seemingly filed before the release was made.

2) Why aren't you involved in acceptance testing, if you see a problem with how it's being done?

Speaking for me, we pay Zend for server licences and imagine that in someway contributes to a professionally run project. Though I have to say we are becoming increasingly unsure as to whether we get any value for money for that, of the security fixes that 5.3.7 fixed I haven't noticed any of them being pushed to Zend Server in a priority fashion and I don't think we've ever had a single support question resolved satisfactorily. Sometimes being a Zend customer seems merely to open you up to sales pushes.

Re:Regression tests are for wimps! (0)

Anonymous Coward | more than 2 years ago | (#37173458)

Regression tests are normally used by idiots with test frameworks, I'd go with people like Niac.
They will not help you find bugs in your software except when you TERRIBLY break shit.

I would guess the framework for the test that passed this goes something like.

if (($test=crypt(something, withMD5))==TRUE)
{
        if (strlen($test) > 0 )
      {
            if ($test==crypt(something,withMD5,$test)) // you know cus you can send encrypted/hash response cus the SALT is always the first X of chars.
        {
            $omgIpassedidiotregressiontesting="yes";
          }
      }
}

All of which will work because it will just return the salt...GOOO REGRESSION TESTING.

I'd go with this bug was found by a user field testing(read as 'actually trying to use it') it and checking the DATA themselfs.

Worked in Software Dev & Support for 12 years. Never once seen a Regression test find something that is broken. FOUND thousands of them by actually using the software after Q/A has regression tested the shit out of it.

Re:Regression tests are for wimps! (1)

EvanED (569694) | more than 2 years ago | (#37175056)

Worked in Software Dev & Support for 12 years. Never once seen a Regression test find something that is broken

I think you're full of BS. In fact, this particular bug was found by a regression test; just no one noticed because they have so many failing tests because their process is non-existent.

Re:Regression tests are for wimps! (1)

Robert Zenz (1680268) | more than 2 years ago | (#37175468)

Never once seen a Regression test find something that is broken.

I think I speak for many developers: Then you're doing it wrong.

Re:Regression tests are for wimps! (1)

AvitarX (172628) | more than 2 years ago | (#37173524)

I know, that's the type of thing we expect from debian when working with cryptography.

Re:Regression tests are for wimps! (2)

GPLHost-Thomas (1330431) | more than 2 years ago | (#37173706)

Few things you are failing in here. First, "Debian" is down to one guy when it comes to packaging PHP. More or less, Ondej Surý does it all, since last year, Raphael Geissert started being busy. I myself work more on packaging PEAR packages, and I have enough work. So if you want things to become better for the packaging of PHP in Debian, then you need to contribute! Create a new user on Alioth, register the project and the pkg-php-maint list, and start helping. Because for sure, we don't have, in Debian, the time to do the programming for more unit testing than it is available in upstream. However, I believe it'd be nice to have the upstream unit testing added the to Debian build process. That would avoid such "surprise"! :)

And the second thing, I posted it on another thread: Debian is *NOT* affected by this, since the crypt() function of php is using the system implementation, not the one of PHP, at least when available (this isn't the case of blowfish which isn't available, so blowfish is affected, but not md5 for example).

Re:Regression tests are for wimps! (1)

Short Circuit (52384) | more than 2 years ago | (#37173748)

Not to dismiss the serious amount of time and effort you, Ondej, Raphael and all packagers put in, but I'm pretty sure the parent was making a joking reference to the OpenSSL entropy bug.

Re:Regression tests are for wimps! (0)

Anonymous Coward | more than 2 years ago | (#37173804)

He's talking about how everyone now has openssh-blacklist installed. Not about anything Debian might have had to do with php.

Re:Regression tests are for wimps! (1)

AvitarX (172628) | more than 2 years ago | (#37174160)

I was more referencing debian creating a flaw openssl by sloppy patching crypto related areas.

Re:Regression tests are for wimps! (0)

Anonymous Coward | more than 2 years ago | (#37174806)

I'm seriously astounded that the php development community doesn't have acceptance testing around this sort of thing.

They do, and you're it.

Rut Roh (1)

jhoegl (638955) | more than 2 years ago | (#37173244)

Rut Roh raggy!

When will MD5 be let to die as hash for passwords? (2, Informative)

c0lo (1497653) | more than 2 years ago | (#37173300)

Re:When will MD5 be let to die as hash for passwor (1)

Anonymous Coward | more than 2 years ago | (#37173400)

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.

Re:When will MD5 be let to die as hash for passwor (1)

DarwinSurvivor (1752106) | more than 2 years ago | (#37173654)

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?

Re:When will MD5 be let to die as hash for passwor (1)

simcop2387 (703011) | more than 2 years ago | (#37173822)

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.

Re:When will MD5 be let to die as hash for passwor (2)

mgiuca (1040724) | more than 2 years ago | (#37174596)

Read up on the difference between Collision attack [wikipedia.org] and Preimage attack [wikipedia.org] .

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.

Re:When will MD5 be let to die as hash for passwor (1)

subreality (157447) | more than 2 years ago | (#37173440)

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.

Re:When will MD5 be let to die as hash for passwor (0)

Anonymous Coward | more than 2 years ago | (#37173738)

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.

Re:When will MD5 be let to die as hash for passwor (0)

Anonymous Coward | more than 2 years ago | (#37174294)

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.

Re:When will MD5 be let to die as hash for passwor (1)

QuasiSteve (2042606) | more than 2 years ago | (#37173460)

Does salting garbage result in something edible?

Well, yes?
http://en.wikipedia.org/wiki/Salt_(cryptography) [wikipedia.org]

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.

Re:When will MD5 be let to die as hash for passwor (1)

c0lo (1497653) | more than 2 years ago | (#37173590)

Does salting garbage result in something edible?

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.

Re:When will MD5 be let to die as hash for passwor (3, Informative)

rthille (8526) | more than 2 years ago | (#37173642)

What's fixed by using salt in your passwords is that the leaked password file can't be compared against a precomputed password dictionary.

Re:When will MD5 be let to die as hash for passwor (1)

Short Circuit (52384) | more than 2 years ago | (#37173854)

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.

Re:When will MD5 be let to die as hash for passwor (1)

Goaway (82658) | more than 2 years ago | (#37174088)

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.

Re:When will MD5 be let to die as hash for passwor (1)

Short Circuit (52384) | more than 2 years ago | (#37174158)

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.

Re:When will MD5 be let to die as hash for passwor (1)

marka63 (1237718) | more than 2 years ago | (#37174326)

For passwords it's more like: echo "MD5${SALT}"`echo -n "${SALT}${DATA}"|md5sum`
where ${SALT} is random and unique to the user.

Re:When will MD5 be let to die as hash for passwor (1)

Anonymous Coward | more than 2 years ago | (#37175482)

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.

Re:When will MD5 be let to die as hash for passwor (1)

Firehed (942385) | more than 2 years ago | (#37174502)

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.

Use both static and dynamic salts (1)

F69631 (2421974) | more than 2 years ago | (#37174994)

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.

PHK MD5 (0)

Anonymous Coward | more than 2 years ago | (#37175804)

-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.

Re:When will MD5 be let to die as hash for passwor (1)

Arancaytar (966377) | more than 2 years ago | (#37173592)

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.

Re:When will MD5 be let to die as hash for passwor (1)

QuasiSteve (2042606) | more than 2 years ago | (#37175788)

If you know what a salt is, you should also know that using the same salt for different accounts is very very bad.

Yep - but sadly commonplace.

Re:When will MD5 be let to die as hash for passwor (3, Informative)

Arancaytar (966377) | more than 2 years ago | (#37173520)

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...)

Re:When will MD5 be let to die as hash for passwor (1)

c0lo (1497653) | more than 2 years ago | (#37173776)

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?

Re:When will MD5 be let to die as hash for passwor (1)

norpy (1277318) | more than 2 years ago | (#37174224)

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.

Re:When will MD5 be let to die as hash for passwor (1)

ais523 (1172701) | more than 2 years ago | (#37174278)

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...

Re:When will MD5 be let to die as hash for passwor (2)

cduffy (652) | more than 2 years ago | (#37174418)

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.

Re:When will MD5 be let to die as hash for passwor (0)

Anonymous Coward | more than 2 years ago | (#37174468)

finding a collision

it's not a "collision", it's a "preimage". these are technical terms with specific meanings.

PHP Bug #55439 FIXED (Aug 20) (1)

Anonymous Coward | more than 2 years ago | (#37173328)

This bug has been fixed already. See https://bugs.php.net/bug.php?id=55439 [php.net]
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

Re:PHP Bug #55439 FIXED (Aug 20) (4, Informative)

nedlohs (1335013) | more than 2 years ago | (#37173514)

Nope.

$valid will be the return value of crypt which will be true in the non-broken code as well.

$crypted == crypt($pw, $salt)

will always be true in the broken code, if $crypted was created with any old password and the same salt.

Of course if you have existing such password, they'll always match false, so no one is going to be able to change their password and trigger the problem anyway :)

Perhaps THIS is the reason why THIS occurs? (-1)

Anonymous Coward | more than 2 years ago | (#37173380)

LAMP is the favored attack for phishers & spammers:

http://www.theregister.co.uk/2011/06/10/domains_lamped/ [theregister.co.uk]

---

PERTINENT QUOTE:

"Phishers compromise LAMP-based websites for days at a time and hit the same victims over and over again, according to an Anti-Phishing Working Group survey.

Sites built on Linux, Apache, MySQL and PHP are the favoured targets of phishing attackers,"

---

* You guys here that are "Pro-*NIX" can call me "troll" ALL YOU LIKE, but the facts are the facts above... now, it's just time to "man up/own-up-to-it" is all, & hope your dev teams can fix it is all!

(I'm sure they can, & this does EVERYONE good (especially those of us who use sites built on the LAMP stack (most likely ALL OF US @ some point because of the mass usage of LAMP out there)))

APK

P.S.=> Yes, face it: Sometimes, a "punch-in-the-head" actually works to get things done, correctly - &, imo @ least? This qualifies as "one of those times..."

(Also, this goes to ANY dev. team out there under the sun, not just LAMP folks)

So, in the end/bottom-line: Just try to look @ this as a GOOD THING (that it's one they actually caught & can most likely fix!)

... apk

Re:Perhaps THIS is the reason why THIS occurs? (4, Funny)

ledow (319597) | more than 2 years ago | (#37173494)

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.

Here is "dickhead's" fact-based reply then (-1)

Anonymous Coward | more than 2 years ago | (#37173726)

Where YOU like it, or not? Well - This data's ALL from a respected source (secunia.com) for known security vulnerabilities unpatched:

NOW - DO pay attention to SQLServer, IIS, & Windows Server itself specifically (vs. Linux, Apache, MySQL, & yes, PHP (our subject here)):

---

Vulnerability Report: Microsoft SQL Server 2008: (08/22/2011)

http://secunia.com/advisories/product/21744/ [secunia.com]

Unpatched 0% (0 of 1 Secunia advisories)

Vulnerability Report: Microsoft Internet Information Services (IIS) 7.x: (08/22/2011)

http://secunia.com/advisories/product/17543/ [secunia.com]

Unpatched 0% (0 of 6 Secunia advisories)

Vulnerability Report: Microsoft Exchange Server 2010: (08/22/2011)

http://secunia.com/advisories/product/28234/ [secunia.com]

Unpatched 0% (0 of 0 Secunia advisories)

Vulnerability Report: Microsoft SharePoint Server 2010: (08/22/2011)

http://secunia.com/advisories/product/29809/ [secunia.com]

Unpatched 0% (0 of 0 Secunia advisories)

Vulnerability Report: Microsoft Forefront Endpoint Protection 2010: (08/22/2011)

http://secunia.com/advisories/product/34343/ [secunia.com]

Unpatched 0% (0 of 1 Secunia advisories)

Vulnerability Report: Microsoft Baseline Security Analyzer 2.x: (08/22/2011):

http://secunia.com/advisories/product/6436/ [secunia.com]

Unpatched 0% (0 of 0 Secunia advisories)

Vulnerability Report: Microsoft Office 2010: (08/22/2011)

http://secunia.com/advisories/product/30529/?task=advisories [secunia.com]

Unpatched 0% (0 of 7 Secunia advisories)

Vulnerability Report: Microsoft Project 2010: (08/22/2011)

http://secunia.com/advisories/product/31177/ [secunia.com]

Unpatched 0% (0 of 0 Secunia advisories)

Vulnerability Report: Microsoft Windows Services for UNIX 3.x: (08/22/2011)

http://secunia.com/advisories/product/5244/ [secunia.com]

Unpatched 0% (0 of 3 Secunia advisories)

Vulnerability Report: Microsoft Internet Explorer 9.x: (08/22/2011)

http://secunia.com/advisories/product/34591/ [secunia.com]

Unpatched 0% (0 of 3 Secunia advisories)

Vulnerability Report: Microsoft Virtual PC 2007: (08/22/2011)

http://secunia.com/advisories/product/14315/ [secunia.com]

Unpatched 0% (0 of 1 Secunia advisories)

Vulnerability Report: Microsoft Visual Studio 2010: (08/22/2011)

http://secunia.com/advisories/product/30853/?task=advisories [secunia.com]

Unpatched 0% (0 of 2 Secunia advisories)

Vulnerability Report: Microsoft DirectX 10.x:
(08/02/2011)

http://secunia.com/advisories/product/16896/ [secunia.com]

Unpatched 0% (0 of 3 Secunia advisories)

Vulnerability Report: Microsoft .NET Framework 4.x
(08/02/2011)

http://secunia.com/advisories/product/29592/ [secunia.com]

Unpatched 0% (0 of 7 Secunia advisories)

Vulnerability Report: Microsoft Silverlight 4.x: (08/22/2011)

http://secunia.com/advisories/product/28947/ [secunia.com]

Unpatched 0% (0 of 1 Secunia advisories)

Vulnerability Report: Microsoft XML Core Services (MSXML) 6.x: (08/22/2011)

http://secunia.com/advisories/product/6473/ [secunia.com]

Unpatched 0% (0 of 4 Secunia advisories)

Vulnerability Report: Microsoft Windows 7: (08/22/2011)

http://secunia.com/advisories/product/27467/?task=advisories [secunia.com]

Unpatched 7% (5 of 80 Secunia advisories)

OR

Vulnerability Report: Microsoft Windows Server 2008: (08/22/2011)

http://secunia.com/advisories/product/18255/?task=advisories [secunia.com]

Unpatched 3% (4 of 148 Secunia advisories)

* Nicest part here is, that the few unpatched vulns ALL have valid easy work arounds, or don't apply to workstations, or can be secured for (by turning off services you don't need, especially on desktops/workstations or by securing them down rights-wise)... can Linux say the same?

---

FACT - THAT'S 3.5x LESS UNPATCHED SECURITY VULNERABILITIES ON MS NEAR ENTIRE ARRAY OF WHAT THEY GIVE YOU FOR BUSINESS & DEVELOPMENT (& I know that LAMP can't say the same & tosses on even MORE errors into the mix for Linux) , THAN IS PRESENT ON THE LINUX 2.6x KERNEL ALONE!

NOW- Toss on the rest of what goes into a Linux distro OR the "LAMP" stack, also (Linux, Apache, MySQL, PHP)?

?

That # goes "up, Up, UP & AWAY...", bigime & even moreso, "increasing that lead, that Linux has", lol, in more unpatched known security bugs present that is (a dubious honor/win, lol, to say the least).

So, that "all said & aside"?

Compare a "*NIX/Open SORES" OS in Linux's "latest/greatest"?:

---

Vulnerability Report: Linux Kernel 2.6.x (08/22/2011)

http://secunia.com/advisories/product/2719/?task=advisories [secunia.com]

Unpatched 6% (16 of 275 Secunia advisories)

---

AND YES, there is a remotely vulnerable unpatched security problem outstanding in Linux there too, unpatched (despite all the "Open 'SORES' eyes" out there to fix it (yea, "right", not!))

* Additionally/again - so it "sinks in":

That's also more than the ENTIRE GAMUT of what MS gives folks to do business & build tools for it as well has & LAMP certainly cannot show less errors in unpatched security vulnerablities than 5 total from MS...

In fact? LAMP is the favored attack for phishers & spammers:

http://www.theregister.co.uk/2011/06/10/domains_lamped/ [theregister.co.uk]

---

PERTINENT QUOTE:

"Phishers compromise LAMP-based websites for days at a time and hit the same victims over and over again, according to an Anti-Phishing Working Group survey.

Sites built on Linux, Apache, MySQL and PHP are the favoured targets of phishing attackers,"

---

COMPARE & CONTRAST WINDOWS RUNNING IN A HIGH-TPM ENVIRONS SERVER-WISE NOW:

Windows also has been running 24x7 since 2005 for NASDAQ, acting as its "OFFICIAL TRADE DATA DISSEMINATION SYSTEM, non-stop, via Windows Server 2003 + SQLServer 2005 in fail-over clustering on the server-front too!

NASDAQ Migrates to SQL Server 2005:

http://www.windowsfs.com/enews/nasdaq-migrates-to-sql-server-2005 [windowsfs.com]

and here:

NASDAQ Uses SQL Server 2005 Ã" Reducing Costs through Better Data Management:

http://blog.sqlauthority.com/2007/09/17/sqlauthority-news-nasdaq-uses-sql-server-2005-reducing-costs-through-better-data-management/ [sqlauthority.com]

(For proof thereof... for coming up on a DECADE OF SOLID UPTIME uninterrupted & "bulletproof + bugfree", @ NASDAQ too, a high-tpm environs, not just a mail or webserver!)

---

You like Apples? HOW DO YOU LIKE THOSE APPLES (compared, apples to apples no less), & the stats above for Linux, kernel only? Well, again - it's also NOT the entire 'gamut/array' of what actually comes in a Linux distro as well!

(E.G.-> Such as the attendant GUI, Windows managers, browsers, etc. that ship in distros too that have bugs, and yes, THEY DO)

THAT ADDS EVEN MORE BUGS that COMPOUNDS THAT # EVEN MORE, and worse, for LINUX!!!

So, so much for "Windows is less secure than Linux" stuff you see around here on /., eh?

(It gets even WORSE for 'Linuxdom' when you toss on ANDROID (yes, it's a LINUX variant too), because it's being shredded on the security-front lately, unfortunately)

BOTTOM-LINE:

What this all comes down to, is all the "Pro-*NIX propoganda straight outta pravda" practically doesn't stand up very well against concrete, verifiable & visible facts now, does it? Nope!

... apk

Re:Here is "dickhead's" fact-based reply then (1)

hoytak (1148181) | more than 2 years ago | (#37174560)

Steve, I know you're pretty animated on stage, but it's just not the same when you're only using boldface and caps.

An application of... "ReVeRsE-PsyChoLoGy" (-1)

Anonymous Coward | more than 2 years ago | (#37175006)

Is your off-topic adhominem attack b.s. the "best you've got", vs. documented concrete, visible, & undeniable stats from a respected site/company that deals in unpatched security vulnerabities data here -> http://developers.slashdot.org/comments.pl?sid=2392436&cid=37173726 [slashdot.org]

?

* Apparently so - "U FAIL", troll... & badly - period!

APK

P.S.=> LMAO - I mean, really: Again - Is your "b.s." off topic adhominem attack forums "illogic-logic" here the "best" you could come up with?

Pretty pitiful on YOUR part, & those like you, as per your "ilk's" usual "modus operandi"...

Please - See here again quoting you again for reference (albeit in "ReVeRsE-PsyChoLoGy" style, as I am "wont to do" vs. off-topic illogical adhominem attack spewing trolls such as yourself):

".spac dna ecafdlob gnisu ylno er'uoy nehw emas eht ton tsuj s'ti tub ,egats no detamina ytterp er'uoy wonk I ,evetS" - by hoytak (1148181) ANOTHER "ne'er-do-well" /. OFF-TOPIC TROLL on Monday August 22, @11:44PM (#37174560) Homepage

"???"

Uhm... Could we get a translation of that off-topic "troll-speak/trolllanguage" of yours, please?

---

* And, you're an off-topic adhominem attack forums "illogic-logic" utilizing troll - no questions asked...SEE MY SUBJECT LINE ABOVE!

Yes, it must have just have been another off-topic done nothing of significance with his life troll spewing his off-topic forums "illogic-logic" adhominem attack b.s. again & not contributing to the ongoing conversations.

Oh well - No biggie!

("ReVeRsE-PsYcHoLoGy", for trolls - Courtesy of this code by "yours truly" in less than 1 second flat):

---

#TrollTalkComReversePsychologyKiller.py (Ver #2 by APK)

def reverse(s):
    try:
        trollstring = ""
        for apksays in s:
        trollstring = apksays + trollstring
    except:
        print("error/abend in reverse function")
    return trollstring

s = ""
print reverse(s)

try:
  s = "Insert whatever 'trollspeak/trolllanguage' gibberish occurs here..."
  s = reverse(s)
  print(s)
except Exception as e:
  print(e)

---

... apk

Re:An application of... "ReVeRsE-PsyChoLoGy" (0)

Anonymous Coward | more than 2 years ago | (#37175730)

You do realize that nobody understands what you're saying? There's no point in writing pages of text, half in boldface, if it's all incoherent and barely makes sense. Not only that, the poster you replied to was not trolling, but simply pointing out the flawed reasoning in saying "LAMP is a popular target" without further specification. For example, the study you linked to doesn't say how they selected their respondents.

Also, your reverse function is terrible, use indexes.

Re:Perhaps THIS is the reason why THIS occurs? (0)

jonahbron (2278074) | more than 2 years ago | (#37173734)

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.

According to SECUNIA? You're WRONG! (-1)

Anonymous Coward | more than 2 years ago | (#37173834)

Seems IIS 7, Windows Server 2008, SQLServer 2008, & Visual Studio 2010 (& more that comes from MS that has to do with online development) show only 4 unpatched security vulnerabilities...

* That's 4x LESS THAN THE LINUX KERNEL ALONE, mind you...!

AND, I'm also keeping things "Apples-to-Apples" here too, since you used the word "APPLE" (or rather, Mac, lol), ok?

Databases to Databases
Dev Tools to Dev Tools
OS to OS
Webservers to Webservers

" I guaran-dang-tee you that IIS servers aren't any safer than a LAMP stack." - by jonahbron (2278074) on Monday August 22, @08:59PM (#37173734)

Oh, really? Take a look below then... "read 'em & weep" vs. your statement:

---

Vulnerability Report: Microsoft SQL Server 2008: (08/22/2011)

http://secunia.com/advisories/product/21744/ [secunia.com]

Unpatched 0% (0 of 1 Secunia advisories)

Vulnerability Report: Microsoft Internet Information Services (IIS) 7.x: (08/22/2011)

http://secunia.com/advisories/product/17543/ [secunia.com]

Unpatched 0% (0 of 6 Secunia advisories)

Vulnerability Report: Microsoft Office 2010: (08/22/2011)

http://secunia.com/advisories/product/30529/?task=advisories [secunia.com]

Unpatched 0% (0 of 7 Secunia advisories)

Vulnerability Report: Microsoft Internet Explorer 9.x: (08/22/2011)

http://secunia.com/advisories/product/34591/ [secunia.com]

Unpatched 0% (0 of 3 Secunia advisories)

Vulnerability Report: Microsoft Visual Studio 2010: (08/22/2011)

http://secunia.com/advisories/product/30853/?task=advisories [secunia.com]

Unpatched 0% (0 of 2 Secunia advisories)

Vulnerability Report: Microsoft .NET Framework 4.x:
(08/02/2011)

http://secunia.com/advisories/product/29592/ [secunia.com]

Unpatched 0% (0 of 7 Secunia advisories)

Vulnerability Report: Microsoft Silverlight 4.x: (08/22/2011)

http://secunia.com/advisories/product/28947/ [secunia.com]

Unpatched 0% (0 of 1 Secunia advisories)

Vulnerability Report: Microsoft XML Core Services (MSXML) 6.x: (08/22/2011)

http://secunia.com/advisories/product/6473/ [secunia.com]

Unpatched 0% (0 of 4 Secunia advisories)

Vulnerability Report: Microsoft Windows 7: (08/22/2011)

http://secunia.com/advisories/product/27467/?task=advisories [secunia.com]

Unpatched 6% (5 of 80 Secunia advisories)

OR

Vulnerability Report: Microsoft Windows Server 2008: (08/22/2011)

http://secunia.com/advisories/product/18255/?task=advisories [secunia.com]

Unpatched 3% (4 of 148 Secunia advisories)

---

Don't believe it? Don't argue with me... argue with the report I posted, and the stats in the link above...

APK

P.S.=> I *think* you "spoke too soon" pal... lol! So, again:

Don't argue with ME, argue with the report in my 1st post you replied to, AND THE STATS POSTED FROM A REPUTABLE & RELIABLE SITE FOR UNPATCHED SECURITY VULNERABILITIES!

"m'kay"?

Oh, & "while you're @ it"? Why don't you post the vulnerabilities unpatched counts for MySQL, PHP, & Apache while you're @ it so we can "compare notes" from SECUNIA's data? Or, do I have to now too?? I already did with the Linux 2.6x series kernel alone showing 4x the amount of unpatched security vulnerabilities that much above AND FAR MORE in other posts here, than MS' stuff... by FAR!

... apk

"Best U have" is effete "mod downs"? (-1)

Anonymous Coward | more than 2 years ago | (#37174306)

See subject-line boys, & please: DO read these facts:

http://developers.slashdot.org/comments.pl?sid=2392436&cid=37173726 [slashdot.org]

and here too:

http://developers.slashdot.org/comments.pl?sid=2392436&cid=37173834 [slashdot.org]

* BECAUSE ALL THE "EFFETE MOD-DOWN 'RETALIATIONS'" in the WORLD, do NOT stand up to concrete, visible, & verifiable facts... period!

APK

P.S.=> Funny also how NOBODY was willing to "meet my challenge" & post the #'s on SECUNIA's unpatched security vulnerabilities on:

1.) MySQL
2.) Apache
3.) PHP (our subject here)

Because the Linux kernel 2.6x ALONE has 3.5-4x the amount of unpatched security vulnerablities ALONE vs. nearly ALL OF WHAT MICROSOFT GIVES FOLKS TO CREATE WEBSITES WITH & HOST THEM ON ALSO, per secunia.com's data on that subject!

(Funny THAT, eh? Not!)

... apk

It is not a crypto bug.. (1)

Anonymous Coward | more than 2 years ago | (#37173424)

.. if the code never calls the crypto. That is the case here.

Poor QA (3, Informative)

TheNinjaroach (878876) | more than 2 years ago | (#37173448)

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 [php.net] 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.

JSP doesn't have these problems (-1)

Anonymous Coward | more than 2 years ago | (#37173498)

I tried JSP myself and I think it is awesome. Now that PHP is dying come and join us in the great experienmce JSP is. The Internet will become faster and more streamlined with this awesome technology. It can even do HTML, but faster.

Call me for more information on JSP and you will get a golden tie clip for free!

Re:JSP doesn't have these problems (1)

jonwil (467024) | more than 2 years ago | (#37173758)

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)

Most distributions *not* affected by this! (4, Informative)

GPLHost-Thomas (1330431) | more than 2 years ago | (#37173628)

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 [debian.org]

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...

Re:Most distributions *not* affected by this! (2)

EvanED (569694) | more than 2 years ago | (#37175090)

The internal crypt() function of PHP is only there whenever the system function doesn't exist.

This is not correct.

Ondrej's post you link to is specifically referring to the patched version of PHP that you get from the Debian repository. One of the patches Ondrej applies makes PHP use the system crypt(). Without that patch -- with the stock PHP code -- PHP uses its own crypt(). Now, other distributions might apply Ondrej's patch, but I certainly wouldn't count on it, and you definitely will have a broken crypt() if you get the stock PHP.

For my source, I again cite an email from Ondrej, this time to the PHP list http://marc.info/?l=php-internals&m=131404279532421&w=2 [marc.info]

In that email, he suggests to the PHP folks that they should apply his patch.

Explanation of Bug (0)

Anonymous Coward | more than 2 years ago | (#37174072)

Here is a good write-up of the bug:

http://pwnhome.wordpress.com/2011/08/22/php-crypt-bug/

Correct me if I'm wrong (1)

magamiako1 (1026318) | more than 2 years ago | (#37174118)

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.

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 /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.

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.

Re:Correct me if I'm wrong (0)

Anonymous Coward | more than 2 years ago | (#37174130)

You are wrong. Salts are used to make rainbow tables (or precomputation) infeasible.

Re:Correct me if I'm wrong (1)

magamiako1 (1026318) | more than 2 years ago | (#37174486)

TLDR: "In this case, the salt generation prevents the generation of usable rainbow tables."

Re:Correct me if I'm wrong (1)

fbjon (692006) | more than 2 years ago | (#37175742)

Just one small but important tl;dr addendum: "...use a RANDOM unique salt per password."

Who uses that? (1)

Just Some Guy (3352) | more than 2 years ago | (#37174340)

Everyone should be using mysql_real_crypt by now.

Lack of security people? (1)

allenw (33234) | more than 2 years ago | (#37174368)

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 [github.com] ) before we build a dependency on it ( https://issues.apache.org/jira/browse/HADOOP-7119 [apache.org] ) . But it seems as though getting the right people involved is extremely difficult. :(

Worst of all worlds (3, Interesting)

93 Escort Wagon (326346) | more than 2 years ago | (#37175244)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>