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 responsibility to:
a) Not send passwords over http b) Not send passwords via GET (which is typically logged) c) Hash their passwords
Anything less, and you're putting the public in danger.
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"?
http://www.startssl.com/ will give you a free SSL cert.
They've got a "How to install" section that specifically deals with Apache (and another one which deals with WHM/cPanel if you're using that for your LAMP management).
It's less than an afternoon's work to get up to speed.
Note that you'll need a dedicated ip address (or you might settle for a server running new enough versions of Apache to use SNI - http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI - but that'll still not work for IE6 and very old versions of other browsers - pre 2.0 for Firefox)
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 it is not signed by an authority (more: http://www.namecheap.com/support/knowledgebase/article.aspx/...).
I occasionally quickly cook meals in my kitchen. I never figured out what I should do exactly to set up the dishwasher with detergent, without needing to pay for the detergent.
I just have a simple kitchen and I don't really understand dishwashing. How should I make it "hygienic"?
(That guy would get shut down by the health authorities as soon as he started serving food to the public. Why aren't web developers offering their systems to the public held to basic data safety practices?)
If you'll allow me to shamelessly self-promote. We make it really easy to do this correctly using an email and password at my startup: https://www.dailycred.com/
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.
http://blog.cloudflare.com/easiest-ssl-ever-now-included-aut...
See: http://codahale.com/how-to-safely-store-a-password/ for details.
Good news, everyone: it will!
MD5 is an utterly terrible password hash. It's just about as bad as plaintext. If you're hashing passwords with md5, please fix it and use one of scrypt, bcrypt or PBKDF2 (recommendations are generally in that order) with an acceptable load factor[0]. Go look up mozilla's coding security guide to know how to migrate from a terrible and insecure hash to a secure password hash.
[0] the usual suggestion is that hashing a password should take a few hundred milliseconds on the production hardware, ideally at least half a second and really as much as your users will accept. For scrypt's memory load factor, it should take as much as you can spare.
Hyperbole is just about as bad as murder.
Looks like they were processing the logins using GET instead of POST, unaware it was logging all the requests. Then the log files ended up on an ftp server for anyone to download.
The IEEE is an association, and doesn't actually have any engineers working for it. Likely, their website is outsourced to one of the local web development firms in town.
They've sent me my cleartext password several times before I finally wrote it down in a place I could keep it safe, and I was always thankful.
Also, the default password is something very simple per account. I don't want to go into any more detail on that.
yes, it very much is.
> In most cases what someone could do with my account is to view articles I have paid for
That's not the problem with leaking plaintext accounts. If the user database is compromised, you can safely assume all of the site is and the site's data is leaked as well (or would be if anyone gave a fuck).
The problem of cleatext (or easy to reverse) password databases is twofold:
1. Most users reuse the same password again and again and again. Having their password leaked on site 1 means all of their accounts are now wide open to whoever got the passwords.
2. Even if only the passwords themselves are leaked, this provides a huge dataset of effective, real-world password. This is a treasure trove of human behaviors and enables the improvement of brute-forcing mutators. In fact, one of the most substantial and important events in modern hacking history was the RockYou password leak.
If so, it should be quite interesting if someone uses the IEEE Web Account username/password to re-forward your @ieee.org e-mail somewhere else. I can see all sorts of nefarious activities that can result from this, such as clicking on various "I forgot my password" links that also use your @ieee account in order to get access to other, perhaps more important resources.
given that people signed up using corporate email addresses, this could be used to hack internal networks of companies.
If you're going to hash my password to 16 characters anyway, why can't I type in 20? But if you're going to store it as plaintext, you need to limit what I input.
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.
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.
I checked the ieee.org website and nothing about this has been mentioned yet. Not even a "We're investigating the allegation" snippet of news.
what? how is telling the ieee not completely the right thing to do, as soon as possible?
(this is the source - http://www.dragusin.ro/; seems like an academic rather than a hacker. still, that seems like an odd thing to be uncertain about).
http://www.iovation.com/blog/dutch-hacker-extradited-from-ro...
</sarcasm>
Client-side encryption is the next logical step. Although not perfect, it is better than storing plaintext data on the server.
1. The server is non-malicious and competently written. The passwords are correctly hashed with something like bcrypt or scrypt. (This is super-easy, so server programmers have no excuse for not doing this.) Browser-side hashing has no advantage.
2. The server is non-malicious, but incompetently written, e.g. they store plaintext passwords or some crap like that. Hashing passwords in javascript would help, but it's not as good as fixing the server, and almost certainly a lot harder.
3. The server is malicious. In which case it can serve up malicious javascript, so you're just as screwed.
But the Robert Morris worm wreaked devastation with a 350 word dictionary (and some mangling). And it don't think passwords have changed that much since the late 80s.
(http://www.ieee-security.org/TC/SP2012/papers/4681a538.pdf)
And of course, we now have evidence that educated users practice superior computer security; compare "1234" (the most popular password among the general populace) to "123456" (the most popular password among IEEE members). That's at least 50% more secure!
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?
This is not the right way to deal with the problem.
Authentication security for cloud services should be something that sits in the browser, not (only) on the server. This is done by 2factor auth, but that too relies too much on the server admin being good with security.
Maybe one solution would be that the router everyone has at home doubles as file server, and that all webapps files are stored there instead on the remote server? That would move the responsibility away from web devs (who often behave irresponsibly) to the ones writing the os for the router.
There are of course many ideas that are better than mine, but to let web devs have control of this is evidently not a good one. Something needs to change.
