If you look at the list of hashes that have been submitted, some say 'pending' and some say 'waiting' (or something like that), so I think they are doing it that way.
Unfortunately, some of us here know the empty MD5 well enough to recognise it on site. It's the only one I've ever seen that contains the string '98 foob2'.
I'm not entirely sure what a foob is, but I'm pretty sure we have at least 98 of them here.
Don't worry, if you're password ever turns up on that list, just slashdot it again. The story'll get posted again and then your password will get buried by about 500 slashdotters trying to do a reverse lookup on 'goatse'.
Approximately 30 cpu cycles per byte, rounded up to a block size of 16 bytes, I think. That's assuming you can't vectorize the operations easily. That suggests that an average consumer system could generate the table for this project in approximately a week. Vectorize that correctly and you can probably halve it.
In using the current time, crackers would only need to keep the keyspace equal to (epoch of timestamp based salts) to (current). That is a significantly smaller space than all possible random strings of the same length.
Well, that depends if your random string generator is seeded off current time, or something more random.
Sorry, I just geek out over implementation details.:)
Err... under the standard assumptions of independence of each bit in the result, the changes of finding a collision are 2^128/36^8, which is about 1 in 2^87, or 1 in 10^26. I wouldn't hold my breath waiting for someone to find one.
You missed the point -- if an intruder already has his password hash, they've got control of the system, so why would they benefit from cracking his password.
What he's neglected to consider is that his password hash might be revealed by an exploit that can only read files as root, but not make modifications, thus enabling a crack which allows someone to log in with full access. E.g., an 'htpasswd' file inside a public web directory on which some dull admin had failed to ensure couldn't be accessed by an intruder.
Surely just once will flush all data to the hard disk controller buffers, which will then be flushed to the disk surface during the reset that the BIOS will send them during a warm boot?
They have a computer in the rack in the last article called waggledance! I'd never thought of naming computers after beer before. I've got to wonder why not...
Re:scalability is a dead issue
on
On PHP and Scaling
·
· Score: 2, Informative
My main issue with PHP scalability is the lack of a global context for app-level caching.
This two-tier/logical-three-tier architecture is the only one PHP supports natively.
I'm not sure what you're on, but you can build however-many-tiers-you-like applications with PHP. In fact, PHP supports a number of technologies specificallly designed to communicate with additional tiers, including CORBA, JavaBeans and SOAP.
Let's also discard any caching as again this is something that Java handily accomodates but is not natively (or at least easily) available in PHP due to lack of state
PHP supports persistent state through shared memory blocks trivially. The implementation of data caching schemes that use this feature is not hard.
17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), a database with only 32 connections may be rapidly swamped
Why would you limit your database to serving fewer connections than you have limited your web server to?
PHP supports an option to kill runaway scripts and reclaim their resources after a time limit has elapsed, which handily prevents the infinite loop problems mentioned.
Ok, so now we have a bunch of "persistent" connections that hang around with the process. How long do they hang around?
Until the database closes them or the PHP server process is killed.
What if two threads in the same process want to use a connection?
The connection is locked from the moment a thread acquires it (using the *_pconnect function) until the script using it terminates.
In the worst case, persistent connections make your problem much much worse, because now you have many more connections open to your database.
What does an inactive open connection to the database cost? Not very much, in my experience.
Your arguments have a little merit, but please try to do your research before ranting about a system.
Re:Scalability and Maintainability go hand in hand
on
On PHP and Scaling
·
· Score: 1
PHP will continue to have this problem until someone comes and tells the developers about a nifty invention called 'namespaces'
Namespaces are handly, I'll agree, but I don't see them as a golden-bullet that are impossible to live without.
Let's face it, they don't actually achieve anything that a consistent naming strategy couldn't also achieve.
As far as I'm aware, Java enforces the use of a database abstraction layer. It's called 'JDBC' and is in the package java.sql. If they're using JDBC then switching to another database server would be a matter of changing the contents of two strings (and ensuring compatibility of their data schemas and queries, but that's a problem however you do it).
I'm not aware of any other way to access MySQL from a Java application.
That depends entirely on the complexity of the system you're trying to implement. Scalability has little to do with that. A very frequently used but simple application is probably better implemented in PHP than Java.
In fact, PHP sessions work in almost exactly the same way as a Java servlet session; they store variables in a memory block that is shared between all the PHP processes (as opposed to one that is shared between threads for Java). You can use disk or a database for storage, if you want, but exactly the same options ought to be achievable with Java, surely?
I'm currently running PHP 4.2, a recent Apache 1.3 and Linux 2.4 on a Pentium 100MMX without difficulty.
Re:scalability is a dead issue
on
On PHP and Scaling
·
· Score: 4, Interesting
developers will tend to munge sql calls into the templates, blow off any MVC separation, and get a system that is very hard to keep going for more than a few revisions.
Yes, that is tempting. But, conversely, it's a very useful capability for small projects. For larger projects, you just need to ensure you have the discipline not to use the capabilities.
For instance, here is a site I developed in PHP using a strict model-view separation. There is direct linkage between view and controller and controller and model -- I couldn't be bothered to sort that out for a project of limited size like that one. In a larger project, I'd probably devise some kind of mechanism for that.
You can write unmaintanable code in any language you choose. Discipline is the key.
Re:jsp is a bad idea, but Java is not
on
On PHP and Scaling
·
· Score: 1
Correct me if I'm wrong, but isn't JSP just a simplified syntax for creating servlets by embedding Java code withing an HTML document?
If so, why should this cause performance problems?
(As an aside, I've run a JSP server in the past on a 100MHz pentium, and after the first use of each page performance was OK, so I'm not sure what the big problem is...)
Re:What's Really Going On Here...
on
On PHP and Scaling
·
· Score: 2, Informative
What do you mean "calling mysql directly"? I can assure you that isn't actually possible in Java. MySQL is a C application, Java can't call C code without some kind of intermediate layer.
Also, what's "Database.java" -- if it's part of the MySQL/Java interface layer, this would be perfectly appropriate behaviour.
Slashdot Mirror
The funny thing is, I suspect there are a number of slashdot users who do, in fact, use that password.
You can create a file that generates a specific MD5 digest without using brute force
Can you?
Please, produce a file that generates the following MD5 digest without using brute force:
3fd6f00a87821a120845cf418be70ef0
Hell, I'll even tell you that the file I generated it from is 136 bytes long and contains only ASCII text. 5 lines of it with LF-only line breaks.
Please let me know when you've achieved that.
If you look at the list of hashes that have been submitted, some say 'pending' and some say 'waiting' (or something like that), so I think they are doing it that way.
Unfortunately, some of us here know the empty MD5 well enough to recognise it on site. It's the only one I've ever seen that contains the string '98 foob2'.
I'm not entirely sure what a foob is, but I'm pretty sure we have at least 98 of them here.
You're in luck if the salt is a 2 digit lower-case-alphanumeric one and the password is 6 chars or less. Otherwise, sorry.
(potentially s/in/out of/;s/sorry/congratulations/)
Don't worry, if you're password ever turns up on that list, just slashdot it again. The story'll get posted again and then your password will get buried by about 500 slashdotters trying to do a reverse lookup on 'goatse'.
How long does it take to compute an MD5 Sum?
Approximately 30 cpu cycles per byte, rounded up to a block size of 16 bytes, I think. That's assuming you can't vectorize the operations easily. That suggests that an average consumer system could generate the table for this project in approximately a week. Vectorize that correctly and you can probably halve it.
In using the current time, crackers would only need to keep the keyspace equal to (epoch of timestamp based salts) to (current). That is a significantly smaller space than all possible random strings of the same length.
:)
;)
Well, that depends if your random string generator is seeded off current time, or something more random.
Sorry, I just geek out over implementation details.
Hmmm. Yeah, guess I can relate to that
Hmmm. User ID 686460 suggests user ID 678202 is 'new here' and it gets modded as insightful. Come on!
Oh, and before you mention it, no I've been here for about 6 years.
Err... under the standard assumptions of independence of each bit in the result, the changes of finding a collision are 2^128/36^8, which is about 1 in 2^87, or 1 in 10^26. I wouldn't hold my breath waiting for someone to find one.
I don't believe anyone has yet developed a quantum algorithm for MD5 cracking.
You missed the point -- if an intruder already has his password hash, they've got control of the system, so why would they benefit from cracking his password.
What he's neglected to consider is that his password hash might be revealed by an exploit that can only read files as root, but not make modifications, thus enabling a crack which allows someone to log in with full access. E.g., an 'htpasswd' file inside a public web directory on which some dull admin had failed to ensure couldn't be accessed by an intruder.
Why sync twice?
Surely just once will flush all data to the hard disk controller buffers, which will then be flushed to the disk surface during the reset that the BIOS will send them during a warm boot?
They have a computer in the rack in the last article called waggledance! I'd never thought of naming computers after beer before. I've got to wonder why not...
My main issue with PHP scalability is the lack of a global context for app-level caching.
http://www.php.net/manual/en/ref.sem.php -- system V shared memory. See specifically the functions shm_put_var() and shm_get_var().
This two-tier/logical-three-tier architecture is the only one PHP supports natively.
I'm not sure what you're on, but you can build however-many-tiers-you-like applications with PHP. In fact, PHP supports a number of technologies specificallly designed to communicate with additional tiers, including CORBA, JavaBeans and SOAP.
Let's also discard any caching as again this is something that Java handily accomodates but is not natively (or at least easily) available in PHP due to lack of state
PHP supports persistent state through shared memory blocks trivially. The implementation of data caching schemes that use this feature is not hard.
17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), a database with only 32 connections may be rapidly swamped
Why would you limit your database to serving fewer connections than you have limited your web server to?
PHP supports an option to kill runaway scripts and reclaim their resources after a time limit has elapsed, which handily prevents the infinite loop problems mentioned.
Ok, so now we have a bunch of "persistent" connections that hang around with the process. How long do they hang around?
Until the database closes them or the PHP server process is killed.
What if two threads in the same process want to use a connection?
The connection is locked from the moment a thread acquires it (using the *_pconnect function) until the script using it terminates.
In the worst case, persistent connections make your problem much much worse, because now you have many more connections open to your database.
What does an inactive open connection to the database cost? Not very much, in my experience.
Your arguments have a little merit, but please try to do your research before ranting about a system.
PHP will continue to have this problem until someone comes and tells the developers about a nifty invention called 'namespaces'
Namespaces are handly, I'll agree, but I don't see them as a golden-bullet that are impossible to live without.
Let's face it, they don't actually achieve anything that a consistent naming strategy couldn't also achieve.
As far as I'm aware, Java enforces the use of a database abstraction layer. It's called 'JDBC' and is in the package java.sql. If they're using JDBC then switching to another database server would be a matter of changing the contents of two strings (and ensuring compatibility of their data schemas and queries, but that's a problem however you do it).
I'm not aware of any other way to access MySQL from a Java application.
Ignore me. I misread the GP post.
That depends entirely on the complexity of the system you're trying to implement. Scalability has little to do with that. A very frequently used but simple application is probably better implemented in PHP than Java.
In fact, PHP sessions work in almost exactly the same way as a Java servlet session; they store variables in a memory block that is shared between all the PHP processes (as opposed to one that is shared between threads for Java). You can use disk or a database for storage, if you want, but exactly the same options ought to be achievable with Java, surely?
pentium support was removed?
I'm currently running PHP 4.2, a recent Apache 1.3 and Linux 2.4 on a Pentium 100MMX without difficulty.
developers will tend to munge sql calls into the templates, blow off any MVC separation, and get a system that is very hard to keep going for more than a few revisions.
Yes, that is tempting. But, conversely, it's a very useful capability for small projects. For larger projects, you just need to ensure you have the discipline not to use the capabilities.
For instance, here is a site I developed in PHP using a strict model-view separation. There is direct linkage between view and controller and controller and model -- I couldn't be bothered to sort that out for a project of limited size like that one. In a larger project, I'd probably devise some kind of mechanism for that.
You can write unmaintanable code in any language you choose. Discipline is the key.
Correct me if I'm wrong, but isn't JSP just a simplified syntax for creating servlets by embedding Java code withing an HTML document?
If so, why should this cause performance problems?
(As an aside, I've run a JSP server in the past on a 100MHz pentium, and after the first use of each page performance was OK, so I'm not sure what the big problem is...)
What do you mean "calling mysql directly"? I can assure you that isn't actually possible in Java. MySQL is a C application, Java can't call C code without some kind of intermediate layer.
Also, what's "Database.java" -- if it's part of the MySQL/Java interface layer, this would be perfectly appropriate behaviour.