I never intended, nor did I say that it was an admission of incompetance. All I mean is it is a very common method people use thinking it'll solve the problem, when infact it does not.
In the case of any vanilla unseasoned hash you are just praying noone has managed to put together a complete hash map, i.e.00000000000000000000000000000000 -> ffffffffffffffffffffffffffff in the case of MD5 (The chances of this are fairly small as we can see from this article we have only managed 12M/2^128), or found a way to produce a collision (for which now it very feasible for MD5). Relying on this would be stupid.
The real security benefit from salting isn't that the cracker has to rebuild his hash mapping. It's that it forces them to find a collision that meets certain parameters (without revealing anything about the actual plaintext). Once somebody has your salt/pepper procedure they can apply the same attacks as in my previous paragraph.
However you can do one better by including the plaintext's length in the hash procedure: H(salt + optional_pepper + length(plaintext) + plaintext).
Unless you do this then plain salt and pepper alone is going to leave you buggared if someone gains readonly access to your source code and/or database (pretty easy in a shared server environment).
What I really mean is your users don't trust you enough not to take a casual glance at their passwords if you're sat their twiddling your thumbs. It really depends on the context if that is relevent. The client can't tell if you're hashing their passwords server side anyway (unless it's hashed client side) so establishing trust by hashing is irrelevent.
But you missed the point that we are assuming the cracker knows H(slashdot.orgbaadgerpassword) not H(password). If slashcode adds the "slashdot.orgbaadger" prefix before applying the hash for matching then the generic dictionary attack is useless.
Although it is a referral link it just redirects to "http://www.dreamhost.com/" for me without setting any cookies (I restrict my cookies) or introducing any ?r=username referralish bits into any other links.
Their referral script is obviously either very dumb or very cunning.
function pepperMatch(password, hash) { var pepper = ['po', '3g', '37', 'ax']; var p; for p in pepper {
if (md5(pepper[p] + password) == hash)
return true; } return false; }
Beyond the obvious downside to this (4 times the CPU time for legitimate matches) the advantage is obviously that the cracker has 4 times the bruteforcing to do. But if your security has been comprimised enough to allow someone to find out this hash then you probably have bigger things to worry about.
Maybe tricks like these will come into their own once people realise just increasing hash length or changing the function isn't going to make them any more secure when users still aren't using 'good' passwords.
If you think about it hashing your passwords in a database is almost an admittance either that 1) you're database will probably be comprimised or 2) you're users shouldn't trust you. I wonder if it's possible to grep the likes of MySQL's storage files for MD5 hashes (thereby bypassing the databases authentication)?
Furthermore salts do not have to be large, random or kept local, as you said in sister post. Provided the cracker has to generate a new hash dictionary it has acheived it's task and this means if you're salt doesn't make your plaintext another plaintext thats found in the crackers database, it has acheived it's goal.
Secret, long and random salts known to both sides and never transmitted will produce a MAC.
"slashdot.org<my password>" will render any generic databases like GData useless for Slashdot password searching. It means someone has to build up a Slashdot specific database using a dictionary first. That is all a salt is really for, to inconvenience a dictionary attack.
"slashdot.orgbaadger<my password>" (<site><username><password>) would be better as it means the cracker has to build a database specific to slashdot and my username.
So yes these passwords are salted, using the domain just saves the plugin having to save random salts somewhere.
Assuming open source and free go hand in hand then yes you're correct.
It is of course possible (although fairly unlikely) that developers of a closed source project (read: not necessarily commercial) be gaurentueed certain things when they sign on, such that they have a say with what happens with the software.
This isn't so much a strength of "open source" (read: vague), more a strength of the GPL and the GNU's definition of "free".
Well why not start with the obvious stuff. There is a a threshold of pornography that 99.99% of people will classify as pornography.
Besides non-pornographic websites shouldn't imho be allowed to hog.xxx domains, so somebody somewhere would have to decide what is non-pornographic anyway.
Forcing porn industries away from.com,.org,.net CAN work if they act NOW.
bigtits.com should get priority pre-registration on on bigtits.xxx
If bigtits.net exists and also want bigtits.xxx they should go through the same procedures as any other domain dispute and sort it out, it's not like the porn industry isn't resilient, right?
.xxx domains shouldn't go live until distutes for said domain are solved
when bigtits.com comes up for renewel the.com registry should forbid it do so after say a year of the.xxx being setup.
in the.com ->.xxx switchover period porn sites can redirect.com to.xxx via CNAME records and adult filters can be effective for those too.
profit.;-P
If you ask me, porn sites would welcome not having to put up censored homepages, disclaimers etc. But then again i'm not a pornographer.
Renewable energy is a myth given all our energy comes from the Sun and that is most definately not renewable (unless the universe is infact infinite and we hop from star to star for the rest of eternity).
I've always wondered about the odds of two people agreeing on and complaining about other drivers and actually refering to each other without knowing it.
Giving said rural family access to education and birth control might be beneficial to their immediate happiness and even their survival. But i'd be suprised if it, and many other acts like it, will solve the biggest problem mentioned by the grandparent:
"It didn't eliminate the painful lack of genuine purpose that many of us long for."
Some people turn to religion, some people turn to their imagination (science and glory), some people turn to practicality - either adding to and/or solving the problems they see around them (usually both), some people bum out and try not to think about it at all. Unfortunately I doubt anybody has actually found what they're looking for yet (although many religious zealots like to say they have).
So you see helping out that family isn't going to solve any of the problems grandparent was on about anymore than going into space. Any not going into space isn't likely to help that family out.
So why not try and do both and see what the smeg happens?
Unless you're a web designer who happen to have designed pages for IE (not too unreasonable just a year or so ago) and can't be arsed to remodel for the standards.
I think you can acheive this using the AddHandler directive for.gz files on Apache.
Just have your web application gzip it's output to a file with a.gz extension when it's done, then have Apache server.gz files with priority over.html files...although I haven't tried it yet.
This assumes of course your web application is not dynamic at runtime on a visitor to visitor basis.
Media whore or not his Shields Up test is the best firewall test on the net i've found that you can use without registration. It let's me choose what ports to test etc and has information on all the port numbers in reach.
Slashdot Mirror
I never intended, nor did I say that it was an admission of incompetance. All I mean is it is a very common method people use thinking it'll solve the problem, when infact it does not.
In the case of any vanilla unseasoned hash you are just praying noone has managed to put together a complete hash map, i.e.00000000000000000000000000000000 -> ffffffffffffffffffffffffffff in the case of MD5 (The chances of this are fairly small as we can see from this article we have only managed 12M/2^128), or found a way to produce a collision (for which now it very feasible for MD5). Relying on this would be stupid.
The real security benefit from salting isn't that the cracker has to rebuild his hash mapping. It's that it forces them to find a collision that meets certain parameters (without revealing anything about the actual plaintext). Once somebody has your salt/pepper procedure they can apply the same attacks as in my previous paragraph.
However you can do one better by including the plaintext's length in the hash procedure: H(salt + optional_pepper + length(plaintext) + plaintext).
Unless you do this then plain salt and pepper alone is going to leave you buggared if someone gains readonly access to your source code and/or database (pretty easy in a shared server environment).
What I really mean is your users don't trust you enough not to take a casual glance at their passwords if you're sat their twiddling your thumbs. It really depends on the context if that is relevent. The client can't tell if you're hashing their passwords server side anyway (unless it's hashed client side) so establishing trust by hashing is irrelevent.
LOL good bloody point.
But you missed the point that we are assuming the cracker knows H(slashdot.orgbaadgerpassword) not H(password). If slashcode adds the "slashdot.orgbaadger" prefix before applying the hash for matching then the generic dictionary attack is useless.
Although it is a referral link it just redirects to "http://www.dreamhost.com/" for me without setting any cookies (I restrict my cookies) or introducing any ?r=username referralish bits into any other links.
Their referral script is obviously either very dumb or very cunning.
function pepperMatch(password, hash) {
var pepper = ['po', '3g', '37', 'ax'];
var p;
for p in pepper {
if (md5(pepper[p] + password) == hash)
return true;
}
return false;
}
Beyond the obvious downside to this (4 times the CPU time for legitimate matches) the advantage is obviously that the cracker has 4 times the bruteforcing to do. But if your security has been comprimised enough to allow someone to find out this hash then you probably have bigger things to worry about.
Maybe tricks like these will come into their own once people realise just increasing hash length or changing the function isn't going to make them any more secure when users still aren't using 'good' passwords.
If you think about it hashing your passwords in a database is almost an admittance either that 1) you're database will probably be comprimised or 2) you're users shouldn't trust you. I wonder if it's possible to grep the likes of MySQL's storage files for MD5 hashes (thereby bypassing the databases authentication)?
Furthermore salts do not have to be large, random or kept local, as you said in sister post. Provided the cracker has to generate a new hash dictionary it has acheived it's task and this means if you're salt doesn't make your plaintext another plaintext thats found in the crackers database, it has acheived it's goal.
Secret, long and random salts known to both sides and never transmitted will produce a MAC.
This is lightly salted.
"slashdot.org<my password>" will render any generic databases like GData useless for Slashdot password searching. It means someone has to build up a Slashdot specific database using a dictionary first. That is all a salt is really for, to inconvenience a dictionary attack.
"slashdot.orgbaadger<my password>" (<site><username><password>) would be better as it means the cracker has to build a database specific to slashdot and my username.
So yes these passwords are salted, using the domain just saves the plugin having to save random salts somewhere.
And blocking all outgoing connections to websites that aren't family friendly?
:o
How are you going to stop young kids seeing things they shouldn't if people in the streets can surf pr0n? Rely on personal responsibility? NEVER!
Offtopic somewhat but what naming convention do most hardened PHP developers prefer?
Assuming open source and free go hand in hand then yes you're correct.
It is of course possible (although fairly unlikely) that developers of a closed source project (read: not necessarily commercial) be gaurentueed certain things when they sign on, such that they have a say with what happens with the software.
This isn't so much a strength of "open source" (read: vague), more a strength of the GPL and the GNU's definition of "free".
Well why not start with the obvious stuff. There is a a threshold of pornography that 99.99% of people will classify as pornography.
.xxx domains, so somebody somewhere would have to decide what is non-pornographic anyway.
Besides non-pornographic websites shouldn't imho be allowed to hog
If you ask me, porn sites would welcome not having to put up censored homepages, disclaimers etc. But then again i'm not a pornographer.
Ludicrous speed... go!
Renewable energy is a myth given all our energy comes from the Sun and that is most definately not renewable (unless the universe is infact infinite and we hop from star to star for the rest of eternity).
I've always wondered about the odds of two people agreeing on and complaining about other drivers and actually refering to each other without knowing it.
Giving said rural family access to education and birth control might be beneficial to their immediate happiness and even their survival. But i'd be suprised if it, and many other acts like it, will solve the biggest problem mentioned by the grandparent:
"It didn't eliminate the painful lack of genuine purpose that many of us long for."
Some people turn to religion, some people turn to their imagination (science and glory), some people turn to practicality - either adding to and/or solving the problems they see around them (usually both), some people bum out and try not to think about it at all. Unfortunately I doubt anybody has actually found what they're looking for yet (although many religious zealots like to say they have).
So you see helping out that family isn't going to solve any of the problems grandparent was on about anymore than going into space. Any not going into space isn't likely to help that family out.
So why not try and do both and see what the smeg happens?
...you mean produce more nukes and hide them even better than the ones in Iraq? :P Behind the moon perhaps.
Yeah i've noticed #2 aswell.
Unless you're a web designer who happen to have designed pages for IE (not too unreasonable just a year or so ago) and can't be arsed to remodel for the standards.
I think you can acheive this using the AddHandler directive for .gz files on Apache.
.gz extension when it's done, then have Apache server .gz files with priority over .html files...although I haven't tried it yet.
Just have your web application gzip it's output to a file with a
This assumes of course your web application is not dynamic at runtime on a visitor to visitor basis.
Did anyone else click the PRADO link see TForm, TButton and TTextbox and just say to themselves "Delphi programmer"?
I don't have a point. I just thought it was kinda neat.
Media whore or not his Shields Up test is the best firewall test on the net i've found that you can use without registration. It let's me choose what ports to test etc and has information on all the port numbers in reach.
Care to make an alternative recommendation?
A PC that can kill you in a poorly ventilated room?
Maybe you should rip the drive out of that PPro200 or something and..like..look into an exorcist for the other other one.