A conversation I had with my littlest sister this morning:
missmag: http://myspace04.myphotos.cc/clarissa17.pif missmag: lol thats cool sheep.: what is cool? It's a pif, don't run those. missmag: lol no its not its a virus sheep.: holy crap, you're finally trying to follow in your brother's footsteps? missmag: lol thats cool sheep.: damn straight, I'll download it now. Let's see which of us can figure out what it does first. It'll be a game! missmag: lol no its not its a virus sheep.: uhhh.. I'm noticing that you're repeating yourself. missmag: lol thats cool sheep.: oh okay, I didn't know that's what kids were into now. missmag: http://myspace04.myphotos.cc/clarissa17.pif sheep.: yeah, I knew myspace was a big hit. sheep.: back in my day it was BBSing, we used to trade porn for games and games for porn. missmag: lol thats cool sheep.: yeah, it got to be really popular community-wise, but I guess you all like myspace cause it's the new "hip" thing, right? missmag: lol no its not, its a virus sheep.: yeah I was thinking the same thing about livejournal missmag: lol thats cool sheep.: Okay now I'm certain there's something wrong, Maggie, are you there? missmag: lol no its not, its a virus sheep.:...
The EFF is like the boy who cried wolf. They cried wolf so loudly at every single infringement that now something serious like the Sony rootkit happens and now we question whether or not their even effective. They NEED to be for this.
Wow. I never thought I'd see the day that the Slashdot editors whored for a spyware/adware company.
Do you guys really think we're *that* gullible? Posting a link to this article does nothing either way when the entire presumption of interest in this "rising star" is flawed. No one here cares about Claria, all our anti-spyware and anti-adware programs remove it so. Posting an article about it doesn't even give us a rise anymore, it's such a non-issue.
The only assumption one can make then, is that the editors are whoring for any type of publicity (good or bad) they can get to make Claria a new item. This isn't a Sony rootkit-type of story.
Like others have said, this fake email fits in, but still, like *I* said, I've been surprised at the number of IT people that have STILL been propagating it. I guess I figured the parent was one of them. Perhaps I'm wrong, but I suspect they were duped as I almost was.
I've been actually quite surprised at the number of IT people that have been propagating this email. You'd think they'd be able to spot a fake a mile away.
I don't know about the available jobs on the coasts, so I can't comment on them. But in the Midwest where I am at, the only available jobs are for 30-40K with excellent benefits. That's great if you want benefits, but some of just want paid. It gets really ridiculous when you consider that the cost of living of most Midwestern cities is rapidly catching up to the coasts.
There are occasional jobs in the upper ranges, but no one wants to hire. It's even more ridiculous in the security field in the Midwest, as no one wants to hire someone with dangerously technical knowledge here, especially if they are young. There's a level of maturity that you just can't prove in a resume, and the more technical expertise you have, the more of a hiring liability you appear as.
I have told my younger brother's and sister's friends looking at IT-related jobs to look at other majors first. Just because they like their iPods and Bittorrent does not make them technically skilled to compete. I think the real problem lately has been rewarding "management experience" over "technical experience" by some of the major Fortune 500s.
You can reward your managers all you want, but if you aren't hand-over-fist for your geeky tech-types, you're just providing less incentive for truly skilled people to work at your place of employment. And you'll end up getting management-heavy, which ultimately will end up costing you money.
Most PHP / CGI scripts on web servers are world readable. Most databases have a function to read in data from a text file. You do the math.
So now an attacker has purchased an account (using a form of payment that allows them to be identified) on a server through the same hosting provider and just happens to be on the same server as I am. Not only that, but I'm stupid enough to make my scripts world readable? I'm sorry, "most" is a horribly inaccurate term here, and there's nothing left to say but "you are wrong." I'm starting to think you know far less about scripting and common security practices than your initial post would have indicated.
Again, you're suggestion of relying on a random salt to hash with per user is horribly flawed. I made the exact argument before and I will repeat it here:...nearly all modern forum and cms software include variables you are suggested to change, one of which is a salt.
There is *nothing* wrong with the system I'm suggesting. What is wrong with your system is that it relies on a variable that has to be different for each user, and is thus stored in a database which only requires an SQL injection to obtain.
I specifically suggested a static salt + a salt that changes for each hash you generate.
I didn't see the static salt part. If you did, then your argument basically comes down to whether or not the "random salt" is any better. Since I'm arguing that anyone who can get the SQL password hash can get the random salt, it all relatively a moot point, IMHO.
Again, nowhere did I see you even mention the static salt, all I heard you say was that my method was so horribly weak that it was obviously worth commenting on.
A few posters have somewhat addressed the issue in previous Slashdot threads, but no one has really hit it yet. When determining who is at fault and maliciousness of an action, intent is always considered. Not the intent to violate the law, but the intent to do the action that violated the law.
For example, if you walk in to a gas station and grab a 25 cent pack of gum and pay for gas and walk out, you can be held liable for stealing that pack of gum. Not because your intent was to break the law, you obviously intended to do that, but because your intent was to take the pack of gum.
A toddler in the same gas station picking things out of mommy's purse and putting them on the shelves and taking gum off the shelf and putting it in mommy's purse, cannot be held liable for stealing, because they don't even have a concept of taking something that is owned by someone else.
Sony here intended to have their rootkit phone home. They intended for it to hide itself. These are very serious allegations, but none of them are incorrect. Sony might not have wanted to violate Texas spyware law, but it seems clear they did intend to have a piece of spyware that attempted to hide itself and phone home.
That's a huge problem. Sony may very well end up being a martyr for DRM in such a way that no future RIAA member company will even attempt something along these lines for years to come.
If I can do SQL injections there is a very good chance I can get your code.
Wrong. There have been more SQL injection attacks than source disclosure vulnerabilities. Check Secunia if you don't believe me. I'm not commenting on this stuff because I have a bug up my ass, I'm commenting on it because I know it.
What if it is an inside job by someone with access to the code?
Then neither your method or my method will work. However with my method, they *HAVE* to get the source code. With your methods, they don't, they can do SOLELY an SQL injection attack.
In any case, you are trying to defend using a weak hash method by suggesting we depend on security through obscurity - bad idea.
No. I am willing to admit that adding the username to the hashing mechanism would be a great idea. Modern software, especially forum and CMS software like that which I work on, requires that users be able to change their names.
So, you say, base it on the unique user ID that is autoincremented? Sure, that's fine. But supposing my source is open, they can just do an SQL injection and get the UID too. That's why nearly all modern forum and cms software include variables you are suggested to change, one of which is a salt. It's usually included along with the MySQL info.
Not to knock your system, but it is far better to have a $salt variable that the user changes who is using your open source software when they install it, than to base hashes solely on information that is stored in an SQL databse.
Ugh. I cannot believe the level of competence on Slashdot.
WHERE ARE YOU GOING TO STORE THIS RANDOMLY ASSIGNED SALT?
You're not understanding that the purpose of include a salt as a variable in the source is to ELIMINATE the possibility that someone can crack user passwords based solely on data returned from an SQL injection attack.
By using a "random" salt, you're going to have to store it *IN THE DATABASE*. There is actually a higher likelihood that someone will hack your database without using a hardcoded salt than with.
Your arguments saying that "all someone needs is your source and the SQL database" is ridiculous when in your own case of randomly assigned salts, all they need is the SQL database!
Also, there have been FAR MORE SQL injection attacks than source disclosure vulns. So many that source disclosure is so rare that many web app coders actually use hardcoded salts.
It really bothers me when people who have no experience in web app security feel obliged to comment on it.
Salts would make finding second preimages harder but it is already hard.
It is important to note that finding two collisions is only one step of many on the way to total abandonment of a hashing system. Not only that, but for the sake of not being vulnerable to pre-generated MD5 rainbow tables, it is VERY important that you salt your user's passwords.
Essentially, if you're not salting your web app user's passwords, you're taking a risk that you shouldn't have to.
There's a really big problem with your argument that this is a "very bad" salt: You are assuming someone has the code. The majority of SQL injections do not provide the attacker with the code.
Even given your own example is only slightly better in that it uses the username. Oh well, if they have the code, (as you are assuming) they can just use the username which they also pulled from the SQL injection to salt the attempt on the password hash. Salting with the $username only adds maybe minimal complication.
Your mechanism does not make things "much harder" than the example I provided. Only different.
Now, along these lines, one could do (using your suggestion with the $username) sha1(md5($username . $password . 'salt1') . 'salt2' . $GLOBALS['somesetvalue']) and be reasonable secure as long as they didn't switch hosting providers. If one wanted to, they could even throw in the php version or phpini settings. But all that hinges on things remaining the same forever, which isn't likely.
Oh well, at least you didn't say that combining md5 and sha1 weakens the hash. There are some that have claimed such.
I didn't realize what the code was until after I had read other's comments. As you can see from the first reply to my own post, I acknowledge this after the fact. You needn't beg for a mod to -1 the comment.
I'm sorry, I'm noticing in other posts here that this does not actually create a valid input to create a collision based on an existing hash, so ignore the parent for now.
This code just creates two inputs that will collide. Knowing this, I have to say that it looks like it might be a little while yet before MD5 is useless. But the days are certainly ticking down. Might not be a bad idea to start changing the way you salt or store your passwords now.
For those of you who store passwords as hashes in your web apps, I've developed a little "Q & A" post here that explains this as best as possible.
Question: Does this mean all my MD5 passwords for all my users can be cracked? Answer: The short answer is yes, they can be cracked. The long answer is no, not if you used a salt, and the attacker has to get those md5 hashes first. You are not safe you are storing your user's password field input directly to the database ala the php/sql method of:
INSERT INTO users VALUES ('user','" . md5($password) . "');
Question: How should I remedy this? Answer: Always use a salt or salts. For example in the case above you could use this php/sql method instead:
Question: How/Why is this safer? Answer: Collisions are only direct input for the md5 function to get the same md5 hash. So in the above case, $password was directly taken from the user and made into a hash. Assuming an attacker got an SQL injection in and grabbed the database, they could run this collision creator on a hash and produce an input that gave that exact hash.
But, this would be much more difficult with any code that introduced a salt. That is why the second code is better, it includes two salts that the attacker (through his SQL injection) is unable to account for.
Yes, but unfortunately, Red Hat was there first. Similar models will get the proverbial "but how are you any different than Red Hat?". So just because it worked for them doesn't mean someone can start now to try to copy the same model for open source. Red Hat is so comprehensive with their services that to try to compete now, especially since it would be *against* them, is an effort in futility.
Not that this is a bad thing, I'm glad for them, but to say that there is a model that works and to suggest that now others can emulate them and succeed is a bit presumptuous. After all, if their services were "bad", they probably wouldn't be a successful model.
Slashdot Mirror
That's what I was given as the URL, I'm not certain if it is the correct one or not, but it seemed legit at the time.
lol thats cool
lol no its not a nazi spam
Note: The slashdot article says 'lol no this is not a virus.' The CNET article says "lol no its not its a virus".
A conversation I had with my littlest sister this morning:
...
missmag: http://myspace04.myphotos.cc/clarissa17.pif
missmag: lol thats cool
sheep.: what is cool? It's a pif, don't run those.
missmag: lol no its not its a virus
sheep.: holy crap, you're finally trying to follow in your brother's footsteps?
missmag: lol thats cool
sheep.: damn straight, I'll download it now. Let's see which of us can figure out what it does first. It'll be a game!
missmag: lol no its not its a virus
sheep.: uhhh.. I'm noticing that you're repeating yourself.
missmag: lol thats cool
sheep.: oh okay, I didn't know that's what kids were into now.
missmag: http://myspace04.myphotos.cc/clarissa17.pif
sheep.: yeah, I knew myspace was a big hit.
sheep.: back in my day it was BBSing, we used to trade porn for games and games for porn.
missmag: lol thats cool
sheep.: yeah, it got to be really popular community-wise, but I guess you all like myspace cause it's the new "hip" thing, right?
missmag: lol no its not, its a virus
sheep.: yeah I was thinking the same thing about livejournal
missmag: lol thats cool
sheep.: Okay now I'm certain there's something wrong, Maggie, are you there?
missmag: lol no its not, its a virus
sheep.:
The EFF is like the boy who cried wolf. They cried wolf so loudly at every single infringement that now something serious like the Sony rootkit happens and now we question whether or not their even effective. They NEED to be for this.
Today it's a rising star
/. editors, we don't care.
Wow. I never thought I'd see the day that the Slashdot editors whored for a spyware/adware company.
Do you guys really think we're *that* gullible? Posting a link to this article does nothing either way when the entire presumption of interest in this "rising star" is flawed. No one here cares about Claria, all our anti-spyware and anti-adware programs remove it so. Posting an article about it doesn't even give us a rise anymore, it's such a non-issue.
The only assumption one can make then, is that the editors are whoring for any type of publicity (good or bad) they can get to make Claria a new item. This isn't a Sony rootkit-type of story.
Sorry
Like others have said, this fake email fits in, but still, like *I* said, I've been surprised at the number of IT people that have STILL been propagating it. I guess I figured the parent was one of them. Perhaps I'm wrong, but I suspect they were duped as I almost was.
Hence the need to point out it is fake.
Just offering some insight, that's all.
It's semi-official.
And now that it has been Slashdotted, it's fully-official.
And it has a history. (Takes a while to load: in Flash)
Sorry, this has been debunked. I was going to mod it down, but instead decided to just post the info:
p
http://www.snopes.com/college/homework/writing.as
I've been actually quite surprised at the number of IT people that have been propagating this email. You'd think they'd be able to spot a fake a mile away.
Because I for one am...
This is the most common grammar mistake made on the Internet, I swear.
Because I, for one, am...
From what I know this includes the GNU Classpath merge and means that Azureus can now be used in a 100% Free-Software system.
That's good for us, considering that the #1 use of Azureus is to pirate 100% commercial software.
I don't know about the available jobs on the coasts, so I can't comment on them. But in the Midwest where I am at, the only available jobs are for 30-40K with excellent benefits. That's great if you want benefits, but some of just want paid. It gets really ridiculous when you consider that the cost of living of most Midwestern cities is rapidly catching up to the coasts.
There are occasional jobs in the upper ranges, but no one wants to hire. It's even more ridiculous in the security field in the Midwest, as no one wants to hire someone with dangerously technical knowledge here, especially if they are young. There's a level of maturity that you just can't prove in a resume, and the more technical expertise you have, the more of a hiring liability you appear as.
I have told my younger brother's and sister's friends looking at IT-related jobs to look at other majors first. Just because they like their iPods and Bittorrent does not make them technically skilled to compete. I think the real problem lately has been rewarding "management experience" over "technical experience" by some of the major Fortune 500s.
You can reward your managers all you want, but if you aren't hand-over-fist for your geeky tech-types, you're just providing less incentive for truly skilled people to work at your place of employment. And you'll end up getting management-heavy, which ultimately will end up costing you money.
Relevant links:- May/008466.html- 11-2005h tm
http://lists.seifried.org/pipermail/security/2005
http://www.computerterrorism.com/research/ie/ct21
http://www.computerterrorism.com/research/ie/poc.
Most PHP / CGI scripts on web servers are world readable. Most databases have a function to read in data from a text file. You do the math.
...nearly all modern forum and cms software include variables you are suggested to change, one of which is a salt.
So now an attacker has purchased an account (using a form of payment that allows them to be identified) on a server through the same hosting provider and just happens to be on the same server as I am. Not only that, but I'm stupid enough to make my scripts world readable? I'm sorry, "most" is a horribly inaccurate term here, and there's nothing left to say but "you are wrong." I'm starting to think you know far less about scripting and common security practices than your initial post would have indicated.
Again, you're suggestion of relying on a random salt to hash with per user is horribly flawed. I made the exact argument before and I will repeat it here:
There is *nothing* wrong with the system I'm suggesting. What is wrong with your system is that it relies on a variable that has to be different for each user, and is thus stored in a database which only requires an SQL injection to obtain.
I specifically suggested a static salt + a salt that changes for each hash you generate.
I didn't see the static salt part. If you did, then your argument basically comes down to whether or not the "random salt" is any better. Since I'm arguing that anyone who can get the SQL password hash can get the random salt, it all relatively a moot point, IMHO.
Again, nowhere did I see you even mention the static salt, all I heard you say was that my method was so horribly weak that it was obviously worth commenting on.
A few posters have somewhat addressed the issue in previous Slashdot threads, but no one has really hit it yet. When determining who is at fault and maliciousness of an action, intent is always considered. Not the intent to violate the law, but the intent to do the action that violated the law.
For example, if you walk in to a gas station and grab a 25 cent pack of gum and pay for gas and walk out, you can be held liable for stealing that pack of gum. Not because your intent was to break the law, you obviously intended to do that, but because your intent was to take the pack of gum.
A toddler in the same gas station picking things out of mommy's purse and putting them on the shelves and taking gum off the shelf and putting it in mommy's purse, cannot be held liable for stealing, because they don't even have a concept of taking something that is owned by someone else.
Sony here intended to have their rootkit phone home. They intended for it to hide itself. These are very serious allegations, but none of them are incorrect. Sony might not have wanted to violate Texas spyware law, but it seems clear they did intend to have a piece of spyware that attempted to hide itself and phone home.
That's a huge problem. Sony may very well end up being a martyr for DRM in such a way that no future RIAA member company will even attempt something along these lines for years to come.
If I can do SQL injections there is a very good chance I can get your code.
Wrong. There have been more SQL injection attacks than source disclosure vulnerabilities. Check Secunia if you don't believe me. I'm not commenting on this stuff because I have a bug up my ass, I'm commenting on it because I know it.
What if it is an inside job by someone with access to the code?
Then neither your method or my method will work. However with my method, they *HAVE* to get the source code. With your methods, they don't, they can do SOLELY an SQL injection attack.
In any case, you are trying to defend using a weak hash method by suggesting we depend on security through obscurity - bad idea.
No. I am willing to admit that adding the username to the hashing mechanism would be a great idea. Modern software, especially forum and CMS software like that which I work on, requires that users be able to change their names.
So, you say, base it on the unique user ID that is autoincremented? Sure, that's fine. But supposing my source is open, they can just do an SQL injection and get the UID too. That's why nearly all modern forum and cms software include variables you are suggested to change, one of which is a salt. It's usually included along with the MySQL info.
Not to knock your system, but it is far better to have a $salt variable that the user changes who is using your open source software when they install it, than to base hashes solely on information that is stored in an SQL databse.
Ugh. I cannot believe the level of competence on Slashdot.
WHERE ARE YOU GOING TO STORE THIS RANDOMLY ASSIGNED SALT?
You're not understanding that the purpose of include a salt as a variable in the source is to ELIMINATE the possibility that someone can crack user passwords based solely on data returned from an SQL injection attack.
By using a "random" salt, you're going to have to store it *IN THE DATABASE*. There is actually a higher likelihood that someone will hack your database without using a hardcoded salt than with.
Your arguments saying that "all someone needs is your source and the SQL database" is ridiculous when in your own case of randomly assigned salts, all they need is the SQL database!
Also, there have been FAR MORE SQL injection attacks than source disclosure vulns. So many that source disclosure is so rare that many web app coders actually use hardcoded salts.
It really bothers me when people who have no experience in web app security feel obliged to comment on it.
Salts would make finding second preimages harder but it is already hard.
It is important to note that finding two collisions is only one step of many on the way to total abandonment of a hashing system. Not only that, but for the sake of not being vulnerable to pre-generated MD5 rainbow tables, it is VERY important that you salt your user's passwords.
Essentially, if you're not salting your web app user's passwords, you're taking a risk that you shouldn't have to.
There's a really big problem with your argument that this is a "very bad" salt: You are assuming someone has the code. The majority of SQL injections do not provide the attacker with the code.
Even given your own example is only slightly better in that it uses the username. Oh well, if they have the code, (as you are assuming) they can just use the username which they also pulled from the SQL injection to salt the attempt on the password hash. Salting with the $username only adds maybe minimal complication.
Your mechanism does not make things "much harder" than the example I provided. Only different.
Now, along these lines, one could do (using your suggestion with the $username) sha1(md5($username . $password . 'salt1') . 'salt2' . $GLOBALS['somesetvalue']) and be reasonable secure as long as they didn't switch hosting providers. If one wanted to, they could even throw in the php version or phpini settings. But all that hinges on things remaining the same forever, which isn't likely.
Oh well, at least you didn't say that combining md5 and sha1 weakens the hash. There are some that have claimed such.
I didn't realize what the code was until after I had read other's comments. As you can see from the first reply to my own post, I acknowledge this after the fact. You needn't beg for a mod to -1 the comment.
Man, I'd like to see a Microsoft-Windows-Compute-Server-2003 cluster of THOSE!
Nah, nevermind. Just doesn't have the same sort of 'ring' to it.
I'm sorry, I'm noticing in other posts here that this does not actually create a valid input to create a collision based on an existing hash, so ignore the parent for now.
This code just creates two inputs that will collide. Knowing this, I have to say that it looks like it might be a little while yet before MD5 is useless. But the days are certainly ticking down. Might not be a bad idea to start changing the way you salt or store your passwords now.
Question: Does this mean all my MD5 passwords for all my users can be cracked?
Answer: The short answer is yes, they can be cracked. The long answer is no, not if you used a salt, and the attacker has to get those md5 hashes first. You are not safe you are storing your user's password field input directly to the database ala the php/sql method of:
Question: How should I remedy this?
Answer: Always use a salt or salts. For example in the case above you could use this php/sql method instead:
Question: How/Why is this safer?
Answer: Collisions are only direct input for the md5 function to get the same md5 hash. So in the above case, $password was directly taken from the user and made into a hash. Assuming an attacker got an SQL injection in and grabbed the database, they could run this collision creator on a hash and produce an input that gave that exact hash.
But, this would be much more difficult with any code that introduced a salt. That is why the second code is better, it includes two salts that the attacker (through his SQL injection) is unable to account for.
That's the way to go!
Yes, but unfortunately, Red Hat was there first. Similar models will get the proverbial "but how are you any different than Red Hat?". So just because it worked for them doesn't mean someone can start now to try to copy the same model for open source. Red Hat is so comprehensive with their services that to try to compete now, especially since it would be *against* them, is an effort in futility.
Not that this is a bad thing, I'm glad for them, but to say that there is a model that works and to suggest that now others can emulate them and succeed is a bit presumptuous. After all, if their services were "bad", they probably wouldn't be a successful model.