91–100 of 138 posts
OT, but why in God's name do some people/countries feel it appropriate to use periods rather than commas as a thousands separator? Do these people just want to cause industrial disasters, medical errors, zombie uprisings, and lost planetary probes?
Earlier quoted context omitted.
> Hyperbole is just about as bad as murder. It's not hyperbole, a rainbow table will give you instant plaintext for 95% of your passwords. And even if you don't want to use one, an off-the-shelf high-end graphic card (~$500) can compute 10 billion md5 hashes per second, plug that in a not-completely-retarded brute-forcer (jack the ripper, oclhashcat) and you've got pretty much the whole database as plaintext in hours…
Really? 155a7a01308fa0807f722c5984bd91fb --- I find "high-end graphic card (~$500) can compute 10 billion md5 hashes per second" a bit unbelievable [but that's progress for ya]. So that's roughly all possible alphanum characters of stringlen 6, each second. So if my calculation is correct (assuming 60 alphanum chars randomly chosen) that's only 7000 years to calculate all 12 char strings? Yes I realise that md5'ed pa…
OT, but why in God's name do some people/countries feel it appropriate to use periods rather than commas as a thousands separator? Do these people just want to cause industrial disasters, medical errors, zombie uprisings, and lost planetary probes?
Maybe those people/countries think the same about people using the comma as a thousands separator instead of a decimal?
Overloading the dot/point symbol as a place-value separator was just insanely goofy. This isn't like the Imperial versus metric system. There are reasons to scrap the Imperial system, but there was no reason to introduce a second notational convention for decimals, especially in a way that seems engineered to mislead and confuse people.
Earlier quoted context omitted.
> Hyperbole is just about as bad as murder. It's not hyperbole, a rainbow table will give you instant plaintext for 95% of your passwords. And even if you don't want to use one, an off-the-shelf high-end graphic card (~$500) can compute 10 billion md5 hashes per second, plug that in a not-completely-retarded brute-forcer (jack the ripper, oclhashcat) and you've got pretty much the whole database as plaintext in hours…
Really? 155a7a01308fa0807f722c5984bd91fb --- I find "high-end graphic card (~$500) can compute 10 billion md5 hashes per second" a bit unbelievable [but that's progress for ya]. So that's roughly all possible alphanum characters of stringlen 6, each second. So if my calculation is correct (assuming 60 alphanum chars randomly chosen) that's only 7000 years to calculate all 12 char strings? Yes I realise that md5'ed pa…
At the highest level, you're missing the issue of specialization and parallelization.
This misunderstanding is partly alluded to by your surprise at the power of GPUs to hash passwords. GPUs can have hundreds or even thousands of what you might think of as "cores", but they're very specialized cores that are only suited to certain kinds of operations. Those operations were originally intended for the problem domain of high-performance graphics, but as it happens, many of those same operations mesh very well with cryptographic hashes. In essence, we've all got specialized massively-parallel password-cracking supercomputers sitting on our desks.
Take this up a level, and you might see the most obvious implication: More $500 graphics cards, more passwords cracked in a given timeframe. Very naïvely speaking, 7,000 $500 graphics cards, $3.5 million. You've just gained the ability to hash every one of those 12-character strings in one year for the cost of a funding round. Oops.
Relatedly, you're talking about cracking a password. That's wrong. Nobody cares about cracking your password, or my password. They're going after passwords, in a massively plural sense.
Start with 100,000 md5 password hashes. Assume the passwords are all 12 characters (they're not) and they're randomly generated (again, not). You don't conduct a brute-force search for every hash, you conduct a brute force search for 100,000 hashes. 7,000 years divided by 100,000 hashes is 25.55 days. With a $500 graphics card, the crackers can brute-force a password every month.
Now, once you realize that the entropy in the average password is not even within an order of magnitude of 60^12, you might begin to see the problem. You'd be lucky to find a password that's 36^8.
That purported 7,000 years is starting to look a lot smaller, isn't it?
This is why we have things like bcrypt and PBKDF2.
I understand that many organizations, even fairly large/respected organizations like the ieee work on a limited "IT" budget, but we've reached the point in our society where it's reasonable to expect these guys to do the bare minimum. Just like everyone working in a restaurant needs to know the basics of food handling in order to avoid getting people sick, everyone who's operating a website with logins has a responsi…
OK, please educate me. (Take me as a model web developer.) I occasionally quickly hack some stuff together in php/javascript/html. I never figured out what should I do exactly to actually set up Apache to work with https, without needing to pay some money to some authorities. I just have a simple LAMP server and I don't really understand Apache. How do I make it "https"?
As for making it https, (hypothetical web developer) most cheap hosting providers actually provide tools for managing certs and apache configs in cpanel. It's not too difficult to do yourself. Basically install mod_ssl and copy paste a standard config, substituting the pathnames for the paths of the certs you got from a CA.
I understand that your average beginning-throw-up-a-website-for-a-business would find this difficult, but they can hire someone for an hour to install their certificates.
Earlier quoted context omitted.
OK, please educate me. (Take me as a model web developer.) I occasionally quickly hack some stuff together in php/javascript/html. I never figured out what should I do exactly to actually set up Apache to work with https, without needing to pay some money to some authorities. I just have a simple LAMP server and I don't really understand Apache. How do I make it "https"?
You can use mod_ssl: http://onlamp.com/onlamp/2008/03/04/step-by-step-configuring... . Other good resources are an easy search away. There are basically two steps, both of which can be at no additional cost: 1. get a certificate, and 2. configure your server to use the certificate. You can generate a certificate yourself, without paying anyone, and it will work fine, but some browsers will throw up a warning page if…
You can get free certificates backed by a CA trusted by most browsers, for example at https://www.startssl.com. There are some limitations (e.g. no wildcard certificates) but it's still much better than a self-signed one.
OT, but why in God's name do some people/countries feel it appropriate to use periods rather than commas as a thousands separator? Do these people just want to cause industrial disasters, medical errors, zombie uprisings, and lost planetary probes?
I wanted an HP15. When I went to buy one, the store was out of stock, but offered to let me have the display unit for something like 10% off. While examining it to make sure it was in good shape, I noticed commas and periods were swapped, and pointed this out.
I had no idea this was normal in some countries, and so assumed it was a defect. So did the sales person, and offered me another 10% off because of that. I decided I could live with that "defect" and bought it.
I was delighted when I got home and read the manual to find that this was simply a setting for internationalization, and and I could easily set it to US mode.
Earlier quoted context omitted.
Can you send MD5 encrypted passwords over HTTP? Can you send passwords over websockets?
It's perfectly possible to use md5 to hash a password in Javascript before transmitting it by HTTP. There isn't a huge security benefit to doing so, however.
Then there's the issue of permissions. That's how these logs were visible. Why can't we scrap this idea of permissions? Plan 9 did it. The shared computing era ended long, long ago. If permissions are too error-prone for even the admin at IEEE to get right, how can users ever be expected to master permissions? They're not even being used for their original purpose - use on systems that were intended to be shared. Instead they're being used on systems that are not supposed to be shared with anyone. Think about this. Why do you need to have permissions on a system that is _not meant to be shared_? Who would introduce that into the design? It is a (poorly) repurposed relic.
As for plain text passwords, unless I read this wrong, the passwords were gleaned from server logs not a password database. It seems that people want to discuss "storing plaintext passwords" even though that had nothing to do with this incident.
How many commenters actually read the article?
Earlier quoted context omitted.
You can use mod_ssl: http://onlamp.com/onlamp/2008/03/04/step-by-step-configuring... . Other good resources are an easy search away. There are basically two steps, both of which can be at no additional cost: 1. get a certificate, and 2. configure your server to use the certificate. You can generate a certificate yourself, without paying anyone, and it will work fine, but some browsers will throw up a warning page if…
tptacek explained to me once how using a self-signed certificate (or more to the point, trusting it) is a bad idea: http://news.ycombinator.com/item?id=2376644 You can get free certificates backed by a CA trusted by most browsers, for example at https://www.startssl.com . There are some limitations (e.g. no wildcard certificates) but it's still much better than a self-signed one.