This is a good point. But the vast majority of impulsive violence is directed against one or two people - and killing one or two people doesn't require a gun (like OJ). I just don't see much upside to gun control laws.
All of my comments are flying right over your head. Please slow down, read and think a little bit before posting the first knee-jerk reaction that comes to mind.
You are entirely missing the point of having a different salt for each password. If you use only a static salt I can run an entire dictionary of words through your hash function and then check the resulting hashes against the password hashes in your database. The number of hashes I must generate is equal to the number of words in my dictionary, or O(m).
Now if you use a different salt for each password, I can't just hash the entire dictionary once and then check for matches. Instead I must hash the entire dictionary for each password (using it's unique salt) - this means I must generate O(m*n) hashes. I have already explained in a previous posting how O(m*n) is much more work than O(m).
Using a unique salt for each hash doesn't improve the security of any one hash (which is what I think is throwing you off), but *drastically* improves the security of the collection of hashes you are generating by making it much harder to launch an effective brute-force attack against them.
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.
Our attacker doesn't need an account on the server. If the database server is running on the same server as the webserver (rather common), our attacker may be able to use the SQL injection attack to get the script source code. Or he may be able to use a buffer overflow in a SQL function to launch a shell with the same permissions as the database server. Or he may be able to exploit some other service or script on the server. There are many attack vectors to get the source of a file on a server. Stop trying to rely on security through obscurity.
Sadly almost all PHP/CGI scripts out there are world readable. This is because the webserver typically runs as an unprivileged user ("nobody") and must be able to access these files. The easiest solution for users and admins is to make the files world readable, so that is just what they do. There are more secure ways to go about this - using suexec/phpsuexec, using groups, etc - but virtually no one does these things. Do you really disagree with this?
Again, you're suggestion of relying on a random salt to hash with per user is horribly flawed.
You give me far too much credit and make me smile with such statements (you might as well say "your suggestion that E=MC^2 is horribly flawed"). These are not my suggestions or methods. If you have discovered some unknown flaw in what I have described, there is an entire world of cryptologists who would love to hear about it. Unix operating systems have used these exact methods in constructing password hashes for many many years (see crypt(3)).
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.
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.
The rest of your comment is nonsense. I specifically suggested a static salt + a salt that changes for each hash you generate. The static hash can be stored in your code if that is what you want to do. If you need to be able to change usernames, just add a password_hash column to your users table.
And these aren't "my methods", this is standard crypto best practices.
If I can do SQL injections there is a very good chance I can get your code. What if it is an inside job by someone with access to the code? In any case, you are trying to defend using a weak hash method by suggesting we depend on security through obscurity - bad idea.
Adding the username makes it much harder. Do you not understand that O(m*n) is considerably harder than O(m)? If you have 1000 users, adding the username means I have to do 1000 TIMES the number of hash calculations to try to crack all of your users passwords. Making something 1000 times harder qualifies as "much harder" in my book.
Using your hashing method I might be able to run a brute force attack on your user's passwords in a day - but if you had used a correct hashing method it would instead take me 1000 times longer or about THREE YEARS! And this is assuming you only have 1,000 users - have 10,000? Try 30 years. Convinced yet?
You should be salting with a static salt plus a salt unique to each hash you make. Something like sha(password + sha(staticsalt+username)) would work fine as long as you don't let users change their usernames. This is standard crypto 101 type stuff.
Combining MD5 and SHA is semi-retarded, but it doesn't make the hash weaker.
(I am only being so blunt because you are giving very bad and dangerous advice in a public forum that could lead to disaster if someone follows it. I understand you are writing PHP and are probably new to programming - you are doing the right thing by even thinking about this stuff. If you are interested, I highly recommend Bruce Schneier's books on crypto, especially Applied Cryptography and Practical Cryptography)
This is a very bad password salting scheme and vulnerable to a dictionary attack. Once I have your database and salts, I can run a dictionary of common passwords through your scheme and crack any weak passwords.
You can make things much harder by having your salt change for each password - include the username for example. Now I have to run my entire dictionary through the sha/md5 function for each user. By doing this, you make the attack O(m*n) instead of O(m) (where m = the number of words in my dictionary and n = the number of users).
And as you mentioned in a follow up post, this code only generates documents with identical md5 sums, it does not generate a document with a given sum. So MD5 is broken for document signing and the like, but secure for password hashing for the time being.
Allow index scans to use an intermediate in-memory bitmap (Tom)
In previous releases, only a single index could be used to do lookups on a table. With this feature, if a query has WHERE tab.col1 = 4 and tab.col2 = 9, and there is no multicolumn index on col1 and col2, but there is an index on col1 and another on col2, it is possible to search both indexes and combine the results in memory, then do heap fetches for only the rows matching both the col1 and col2 restrictions. This is very useful in environments that have a lot of unstructured queries where it is impossible to create indexes that match all possible access conditions. Bitmap scans are useful even with a single index, as they reduce the amount of random access needed; a bitmap index scan is efficient for retrieving fairly large fractions of the complete table, whereas plain index scans are not.
The cheeseshop is currently the closest thing python has to CPAN. Only ~900 modules compared to CPAN's 8,000+, so it still has a way to go. There is also the Vaults of Parnassus.
Also, the daily python url is a great way to keep up with the latest developments in the Python world.
Re:I just want to say thanks.
on
Vim 6.4 Released
·
· Score: 3, Informative
Bram is now taking donations to help fund further Vim development. If you donate >10 euro's, you get to vote on new features. This is a great way for those of us who have written countless thousands of lines of code in Vim to show our appreciation.
The purchase of Innobase by Oracle is a big problem for MySQL AB. If they really want to be a grown-up database vendor, they are going to have to eventually write their own MVCC backend. And they can't easily fork off the GPL InnoDB as they make the vast amount of their money by selling non-GPL licenses of MySQL.
There are other backends for MySQL, but MyISAM doesn't work well with multiple readers+writers due to table locking / lack of MVCC, doesn't offer transactions, etc - and the BDB backend, the closest backend to InnoDB feature-wise is still not considered production quality after many many years.
From what I have seen, InnoDB has become the more popular table handler for new projects and is definately the table handler MySQL AB promotes the most. MyISAM tends to be relegated to mostly read-only tables and legacy use. I really like MySQL's concept of being able to use the right tool for the job when it comes to table handlers, but one of their best tools just got swiped by the 1000lb gorilla next-door! (Oracle may still let them license InnoDB commercially, but can stop at anytime)
Your comment on Postgresql is spot on, and with postgres getting so much easier for new users to get into (auto vacuum, native windows support), Postgresql's complete lack of annoying licensing issues, etc - things still look good for open source databases.
Are you kidding me? Even the anti-war extremists at Iraq Body Count say < 18,000 civilians killed - and they include civilians killed by insurgents, so the number killed by US forces is even lower. Talk about being ill-informed.
It is not possible to diagnose hardware by running software on it. At best you can determine if there is a hardware failure, but no software will be able to nail it down to a specific component all of the time.
Consider a motherboard failure for instance - a failing motherboard can in effect emulate any other hardware failure - ide controller bad? Your software may blame the hard drive. Bus problems can cause memory checks to fail.
I recommend you carry a simple bootable cdrom that loads the entire system (disk i/o, memory i/o and cpu load) and checks for errors. When a system fails these checks all it tells you is the problem is definately hardware and not a buggy driver or other software issue.
"Linux? Good god no, man! Didn't you see what happened when just a bit of the Microsoft source code got leaked? I thought you were up on these things!"
Ha, that reminds me of a recent article on devx. This guy demonstrates how being a little stupid and misinformed can lead you down all kinds of wrong paths.
His argument is that some crazed open source hacker is going to put a back door in an open source program. Further he presents this as a disadvantage of open source when compared to closed software. Because, of course, it is so much easier to hide backdoors in programs that EVERYONE HAS THE SOURCE CODE TO. No one could even hide a backdoor in a program that nobody except the developers have seen the code for. That is unpossible. Right.
This person (I'm not going to say "He" because hey, who knows?) obviously knows their stuff. I don't think they are necessarily immature - could just be a quirky sense of humor (not uncommon for geeks).
I would guess this person is in their late teens or early twenties. If they were any older they would be making 6-figures working for eeye or @stake.
Yeah, right. That might be what AMD says, but everyone knows the PR is supposed to compare to an equivalent p4. IE, PR3200 is supposed to be roughly equivalent to a 3.2Ghz p4.
Your average IT manager or consumer thinks that Mhz are everything and thus a 3200Mhz p4 must be way faster than an Athlon 64 running at a puny 2000Mhz.
But one thing I havent' figured is how to block 'flash ads' (ads using Shockwave plugin!)
I just keep the plugin (/usr/lib/netscape/plugins/libflashplayer.so on my system) chmod'd 000, then chmod it back to 755 when I want to see a flash animation.
That isn't a great solution though, because it's a hassle. Mozilla needs an option to let you allow/disallow plugins by url/domain. So you could disable flash by default and then explicitly enable it on sites where you want to view the flash.
Actually, the submitter was correct. The word "engine" is defined as "A machine that converts energy into mechanical force or motion." Interestingly enough, a motor is defined as "Something, such as a machine or an engine, that produces or imparts motion." Thus you could call an electric motor an engine or an internal combustion engine a motor. All motors are engines, but only some engines are motors.
Nintendo systems have, for ever, been running along with the cockroaches after the nuclear fallout
I take it you never owned an original NES? Everyone I knew back then had a different secret ritual they had to perform to get rid of that damn blinking red light syndrome.
Comments are fine as long as they explain why the code is doing what it is, not what the code does or how it does it (that should be obvious from just looking at the code).
Bad Comment:
/* Disable widget by calling disable() method */
Good Comment:
/* Disable widget so it can't be accidently clicked */
Slashdot Mirror
This is a good point. But the vast majority of impulsive violence is directed against one or two people - and killing one or two people doesn't require a gun (like OJ). I just don't see much upside to gun control laws.
All of my comments are flying right over your head. Please slow down, read and think a little bit before posting the first knee-jerk reaction that comes to mind.
You are entirely missing the point of having a different salt for each password. If you use only a static salt I can run an entire dictionary of words through your hash function and then check the resulting hashes against the password hashes in your database. The number of hashes I must generate is equal to the number of words in my dictionary, or O(m).
Now if you use a different salt for each password, I can't just hash the entire dictionary once and then check for matches. Instead I must hash the entire dictionary for each password (using it's unique salt) - this means I must generate O(m*n) hashes. I have already explained in a previous posting how O(m*n) is much more work than O(m).
Using a unique salt for each hash doesn't improve the security of any one hash (which is what I think is throwing you off), but *drastically* improves the security of the collection of hashes you are generating by making it much harder to launch an effective brute-force attack against them.
Our attacker doesn't need an account on the server. If the database server is running on the same server as the webserver (rather common), our attacker may be able to use the SQL injection attack to get the script source code. Or he may be able to use a buffer overflow in a SQL function to launch a shell with the same permissions as the database server. Or he may be able to exploit some other service or script on the server. There are many attack vectors to get the source of a file on a server. Stop trying to rely on security through obscurity.
Sadly almost all PHP/CGI scripts out there are world readable. This is because the webserver typically runs as an unprivileged user ("nobody") and must be able to access these files. The easiest solution for users and admins is to make the files world readable, so that is just what they do. There are more secure ways to go about this - using suexec/phpsuexec, using groups, etc - but virtually no one does these things. Do you really disagree with this?
You give me far too much credit and make me smile with such statements (you might as well say "your suggestion that E=MC^2 is horribly flawed"). These are not my suggestions or methods. If you have discovered some unknown flaw in what I have described, there is an entire world of cryptologists who would love to hear about it. Unix operating systems have used these exact methods in constructing password hashes for many many years (see crypt(3)).
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.
The rest of your comment is nonsense. I specifically suggested a static salt + a salt that changes for each hash you generate. The static hash can be stored in your code if that is what you want to do. If you need to be able to change usernames, just add a password_hash column to your users table.
And these aren't "my methods", this is standard crypto best practices.
If I can do SQL injections there is a very good chance I can get your code. What if it is an inside job by someone with access to the code? In any case, you are trying to defend using a weak hash method by suggesting we depend on security through obscurity - bad idea.
Adding the username makes it much harder. Do you not understand that O(m*n) is considerably harder than O(m)? If you have 1000 users, adding the username means I have to do 1000 TIMES the number of hash calculations to try to crack all of your users passwords. Making something 1000 times harder qualifies as "much harder" in my book.
Using your hashing method I might be able to run a brute force attack on your user's passwords in a day - but if you had used a correct hashing method it would instead take me 1000 times longer or about THREE YEARS! And this is assuming you only have 1,000 users - have 10,000? Try 30 years. Convinced yet?
You should be salting with a static salt plus a salt unique to each hash you make. Something like sha(password + sha(staticsalt+username)) would work fine as long as you don't let users change their usernames. This is standard crypto 101 type stuff.
Combining MD5 and SHA is semi-retarded, but it doesn't make the hash weaker.
(I am only being so blunt because you are giving very bad and dangerous advice in a public forum that could lead to disaster if someone follows it. I understand you are writing PHP and are probably new to programming - you are doing the right thing by even thinking about this stuff. If you are interested, I highly recommend Bruce Schneier's books on crypto, especially Applied Cryptography and Practical Cryptography)
This is a very bad password salting scheme and vulnerable to a dictionary attack. Once I have your database and salts, I can run a dictionary of common passwords through your scheme and crack any weak passwords.
You can make things much harder by having your salt change for each password - include the username for example. Now I have to run my entire dictionary through the sha/md5 function for each user. By doing this, you make the attack O(m*n) instead of O(m) (where m = the number of words in my dictionary and n = the number of users).
And as you mentioned in a follow up post, this code only generates documents with identical md5 sums, it does not generate a document with a given sum. So MD5 is broken for document signing and the like, but secure for password hashing for the time being.
Postgres 8.1 (currently in Beta) can use multiple indexes per query: http://developer.postgresql.org/docs/postgres/rele ase.html#RELEASE-8-1
Allow index scans to use an intermediate in-memory bitmap (Tom)
In previous releases, only a single index could be used to do lookups on a table. With this feature, if a query has WHERE tab.col1 = 4 and tab.col2 = 9, and there is no multicolumn index on col1 and col2, but there is an index on col1 and another on col2, it is possible to search both indexes and combine the results in memory, then do heap fetches for only the rows matching both the col1 and col2 restrictions. This is very useful in environments that have a lot of unstructured queries where it is impossible to create indexes that match all possible access conditions. Bitmap scans are useful even with a single index, as they reduce the amount of random access needed; a bitmap index scan is efficient for retrieving fairly large fractions of the complete table, whereas plain index scans are not.
The cheeseshop is currently the closest thing python has to CPAN. Only ~900 modules compared to CPAN's 8,000+, so it still has a way to go. There is also the Vaults of Parnassus.
Also, the daily python url is a great way to keep up with the latest developments in the Python world.
Bram is now taking donations to help fund further Vim development. If you donate >10 euro's, you get to vote on new features. This is a great way for those of us who have written countless thousands of lines of code in Vim to show our appreciation.
The purchase of Innobase by Oracle is a big problem for MySQL AB. If they really want to be a grown-up database vendor, they are going to have to eventually write their own MVCC backend. And they can't easily fork off the GPL InnoDB as they make the vast amount of their money by selling non-GPL licenses of MySQL.
There are other backends for MySQL, but MyISAM doesn't work well with multiple readers+writers due to table locking / lack of MVCC, doesn't offer transactions, etc - and the BDB backend, the closest backend to InnoDB feature-wise is still not considered production quality after many many years.
From what I have seen, InnoDB has become the more popular table handler for new projects and is definately the table handler MySQL AB promotes the most. MyISAM tends to be relegated to mostly read-only tables and legacy use. I really like MySQL's concept of being able to use the right tool for the job when it comes to table handlers, but one of their best tools just got swiped by the 1000lb gorilla next-door! (Oracle may still let them license InnoDB commercially, but can stop at anytime)
Your comment on Postgresql is spot on, and with postgres getting so much easier for new users to get into (auto vacuum, native windows support), Postgresql's complete lack of annoying licensing issues, etc - things still look good for open source databases.
I am fine with any DRM as long as it is easily removed without degrading the quality of the original file. The CSS protection on DVD's for example.
His first album is available for free from his website, but you have to navigate through all the flash nonsense.
Shortcut for the lazy here.
Hide the projector in the wall / ceiling and this would be a much better trick - just a sheet of glass with a "magic" image on it.
Are you kidding me? Even the anti-war extremists at Iraq Body Count say < 18,000 civilians killed - and they include civilians killed by insurgents, so the number killed by US forces is even lower. Talk about being ill-informed.
Dell has a pretty healthy selection of Linux options these days and of course there's always Penguin Computing
Where do you buy your Linux servers?
It is not possible to diagnose hardware by running software on it. At best you can determine if there is a hardware failure, but no software will be able to nail it down to a specific component all of the time.
Consider a motherboard failure for instance - a failing motherboard can in effect emulate any other hardware failure - ide controller bad? Your software may blame the hard drive. Bus problems can cause memory checks to fail.
I recommend you carry a simple bootable cdrom that loads the entire system (disk i/o, memory i/o and cpu load) and checks for errors. When a system fails these checks all it tells you is the problem is definately hardware and not a buggy driver or other software issue.
See BartPE for a good free solution.
"Linux? Good god no, man! Didn't you see what happened when just a bit of the Microsoft source code got leaked? I thought you were up on these things!"
Ha, that reminds me of a recent article on devx. This guy demonstrates how being a little stupid and misinformed can lead you down all kinds of wrong paths.
His argument is that some crazed open source hacker is going to put a back door in an open source program. Further he presents this as a disadvantage of open source when compared to closed software. Because, of course, it is so much easier to hide backdoors in programs that EVERYONE HAS THE SOURCE CODE TO. No one could even hide a backdoor in a program that nobody except the developers have seen the code for. That is unpossible. Right.
This person (I'm not going to say "He" because hey, who knows?) obviously knows their stuff. I don't think they are necessarily immature - could just be a quirky sense of humor (not uncommon for geeks).
I would guess this person is in their late teens or early twenties. If they were any older they would be making 6-figures working for eeye or @stake.
It's a sad day when even mods don't RTFA (that's Read The Fine Article for all of you lovely people with mod points today :)
... AMD compares their CPUs to a 1Ghz Duron ...
Yeah, right. That might be what AMD says, but everyone knows the PR is supposed to compare to an equivalent p4. IE, PR3200 is supposed to be roughly equivalent to a 3.2Ghz p4.
Your average IT manager or consumer thinks that Mhz are everything and thus a 3200Mhz p4 must be way faster than an Athlon 64 running at a puny 2000Mhz.
Other (non-Nintendo) games can't copy it because it is patented by Nintendo.
But one thing I havent' figured is how to block 'flash ads' (ads using Shockwave plugin!)
I just keep the plugin (/usr/lib/netscape/plugins/libflashplayer.so on my system) chmod'd 000, then chmod it back to 755 when I want to see a flash animation.
That isn't a great solution though, because it's a hassle. Mozilla needs an option to let you allow/disallow plugins by url/domain. So you could disable flash by default and then explicitly enable it on sites where you want to view the flash.
Actually, the submitter was correct. The word "engine" is defined as "A machine that converts energy into mechanical force or motion." Interestingly enough, a motor is defined as "Something, such as a machine or an engine, that produces or imparts motion." Thus you could call an electric motor an engine or an internal combustion engine a motor. All motors are engines, but only some engines are motors.
I take it you never owned an original NES? Everyone I knew back then had a different secret ritual they had to perform to get rid of that damn blinking red light syndrome.
Comments are fine as long as they explain why the code is doing what it is, not what the code does or how it does it (that should be obvious from just looking at the code).
Bad Comment:
/* Disable widget by calling disable() method */
Good Comment:
/* Disable widget so it can't be accidently clicked */
-sean
Or uhmmm....whois.