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 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.
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"?
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)
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.
OK, please educate me. (Take me as a model restauranteur.)
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?)
Because most people grow up knowing how to use dishwashers, but not knowing how to use SSL. Until we get to that point, we should focus on educating and informing people instead of snarking at them and hoping they get shut down.
The OP's (parody) comment is not about using dishwashers, but rather about dishwashing without using any detergent despite knowing that detergent is to dishwashing as SSL Certs is to https ...
and FTR, I did not grow up knowing how to use dishwashers but was quite aware of the basic relationship between the act of dishwashing and detergents. Extrapolating that fundamental relationship to a dishwasher is to say the least -- elementary.
A simple way to side-step the issue entirely is to use an OAuth provider you trust.
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/
That can't possibly work, right? If a user accesses my website over unsecured HTTP, gets sent to an HTTPS DailyCred (or other OAuth provider) site to log in, and back to my unsecured HTTP site, they're still as vulnerable to man-in-the-middle attacks as if the OAuth provider didn't use HTTPS.
In particular, a man-in-the-middle can capture the redirect to DailyCred and instead send the user to some trojaned site to capture their username and password (and then forward it on to you to get a legitimate token, but the password's been leaked in the process).
I don't think it's helpful to say "we do HTTPS so you don't have to". Your users still need to be using HTTPS and preferably HSTS, unless I'm misunderstanding the intended use case. (I'm very happy to see that you guys do HSTS, though!)
All of our inbound links and API calls from our clients are https from the get go. However, you are correct that a man-in-the-middle could rewrite the http website of someone using us to change the links to http from https and then perform a man-in-the-middle attack on that request.
Because of this narrow risk, we encourage our clients to still get ssl certs as they grow. However, when they are small MVPish non-sensitive apps with 50 users, the risk of this kind of attack is very small. (For example, Facebook Connect, which has the same vulnerability I described, would be a much more obvious target with a very high payload.)
The way we see it is getting people who are about to either store plaintext passwords or not salt their hashes correctly or pass them over non-https (like HN by default, boo!) or mess up a dozen other things, we're much more secure.
Unfortunately you do have to pay some money. Godaddy offers certs for 12.00 USD a year, which is probably less than you're paying to host the site.
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.
If you don't want to worry about buying certificates and configuring webservers for HTTPS, check out CloudFlare. It's a bit expensive ($20/month for the first site, $5/month for additional sites) if all you care about is SSL, but they offer a lot more than just SSL:
I think at this point, I think the software community at large is responsible for not solving this problem once and for all. It's clearly preferable to trust each OS/Browser vendor rather than trust each and every web site.
If you want to have a shared folder that you share between people you trust, it's still the simplest solution. It's very low-level, but it works.
Yes, you can buy a cloud offering, but physical disk is still way cheaper than "cloud disk". You don't have all the cloud features, but on the other hand, the data are 100% yours, on a server that you control.
I don't buy that it's "the simplest". Just about every major Linux distro ships w/ SFTP enabled out-of-the-box. How is installing an FTP server easier than just using the built-in SFTP server?
I've been trying to actively discourage the use of FTP for the last 10+ years. It's not an option because it passes passwords in-the-clear. Protocols that pass cleartext authentication should just be off the table today.
I find that positive attitudes towards FTP often seem to correlate with positive feelings towards Telnet, and both seem to correlate with "Not really that comfortable with Nix"*.
The number of times I have had to correct tech-ish friends when they talk about "telnet-ing" into servers is frightening. All of them were relatively technology literate but either didn't do it for a living or got into doing it for a living "by accident". Think your physics major buddy who has only ever used windows on any computer that he owns.
You put people like that in the position to make a call, and I assure you you'll have an FTP server running somewhere in 5 minutes flat.
I believe that random Windows authoring software is vaguely more likely to have FTP built in than SFTP. (But finding good SFTP software for Windows, e.g. WinSCP, is not hard, so this is not much of an argument.)
It's also the case that SFTP requires giving someone an actual user account on your UNIX box, and preferably knowing enough about how to set SSH up to restrict them to SFTP access only. If your server is much more valuable than the data and you don't trust yourself not to get SSH configuration subtly wrong, it's not terribly unreasonable to prefer installing an FTP server to adding a local user and giving someone else a password to it.
I usually have an internal TFTP server set up and laying around somewhere. A lot of embedded devices provide simple support for updating their firmware over TFTP.
If Microsoft every had of built a decent client into Windows Explorer like MacOSX has (rather than the crufty, half baked one they ran with) then it could have been great. As it turns out, it is only really easy to access it through FTP-like programs (separate from Windows Explorer).
Having said that, we had pretty good experiences with WebDrive [1] allowing us to mount WebDAV directories in Windows. Also, Gnome does a pretty good job on Linux with GVFS [2].
Which makes me wonder why approximately everyone has a parser for the common FTP directory listing formats, but I'm not sure I've seen any HTTP client that parses Apache mod_autoindex output or the other big servers' equivalents.
I am not too well-versed in this sphere, but I would also require salting passwords when hashing. It obviously won't help if your database is compromised, but will protect your users (and your database) against the effects of leaks such as these.
> One of these days we will shut down the "Salting password hashes is a useful thing to do."
Uh? Why? It is a useful thing to do. More than that, it is necessary (but not sufficient). There's a reason why all of pbkdf2, bcrypt and scrypt generate salts if you leave them to their own devices.
It's implicitly understood by everyone who cares about this topic that salting is intrinsic to KDFs. I.E. by the time you've read through, and understood http://codahale.com/how-to-safely-store-a-password/, you understand why "salting" your password gains you nothing, because rainbow tables are no longer particularly relevant to cracking passwords. And yes, while there is salting inherent to KDFs, that's not the major feature of them, but an assumed implementation detail.
> rainbow tables are no longer particularly relevant to cracking passwords
If you use a common hash with no salt you can bet your britches the attacker will use rainbow tables!
It's also worth pointing out that rainbow tables aren't the only attack you are exposed to if you don't salt your passwords - it also prevents finding collisions, and massively slows down forward hashing attacks.
Negative on that. Not all algorithms produce the salt internally like bcrypt does--programmers must still be careful to supply a sufficiently lengthy random salt as input to PBKDF2, for example. Labeling folks who know this as stuck in the past or ignorant is a mistake.
Of course a salt will not make a single password harder to attack. A salt will however force you to attack passwords "one at a time" by making precomputed hashes useless.
And there's a reason why high-level libraries like bcrypt handle salt generation and storage internally: if they didn't, people would screw it up. It's amazing how many people blithely use some crazy scheme like
pwhash = md5("this is my salt" + password)
Progress in password hashing security is primarily progress in making things trivially foolproof and then hectoring people into using them.
Well, we need to define the attack if we're going to talk about what will and won't help. Generally when we talk password security, we assume the attack is to discover a large number of users' passwords, not to spoof as one. Additionally, it's more common to get read-only access to the data than it is to be able to execute arbitrary queries against the DB.
I wonder why the website package even wrote a log that included plaintext passwords. That's not IEEE's fault, except perhaps a lapse in judgement to use whatever opensource package.
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.
Only doing that won't help. You might as well be transmitting the password, since someone can just copy the hash and then it would be equivalent to having the password. (Also known as a Pass the Hash attack, http://en.wikipedia.org/wiki/Pass_the_hash).
The right way to do that is Digest authentication, which is a challenge-response mechanism (so you never actually send a password or something equivalently stealable). I call it the right way mostly because it's built in to just about all servers and clients; doing it over HTTP is still not a terribly good idea.
The browser data graph is actually quite interesting. I'm guessing that the slight windows where Firefox edges out Chrome for the top spot corresponds to European users waking up a few hours before North American users.
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!
What concerns me is that I have to renew my IEEE membership very soon, and if they have the wrong logging enabled how can I be assured that they aren't logging me CC details? I've seen it happen in one of my client's production systems, but at least they never put the log files up on a public FTP site.
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.
If they're taking credit card information, they have to be PCI compliant. An auditor should notice pretty quickly if they're logging CC transactions. Not to say it can't happen and you're absolutely right to be suspicious, but if they are there will be repercussions.
If they don't do the processing themselves, they can fill out the self questionaire, which basically amounts to "pay the damn application fee already".
As someone else said, why are there passwords in the logs? If these were submitted via POST (multipart), they would not be visible, right?
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.
Sorry, but the entire purpose of the ieeelog site is to document this breach? Fine...I guess? It just kind of threw me off...I thought it was somehow connected to IEEE-proper, as if it were the dev blog for IEEE.
"For a few days I was uncertain what to do with the information and the data."
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).
This is without doubt terrible, we all know that. But it is not uncommon that web services leak passwords, so common that we are quite accustomed to it and expect it to happen from time to time.
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.
I.E. is actually the best at stopping social engineering attacks on your average consumer because of their SmartScreen technology, which relies completely on feedback from the community, both automatic and manual. No reason to downvote this or the original comment IMO.
Of course the browser can't know this. But one clue for the user is if there is a strict length limit.
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.
That's a fair point. The only way it would work is if an anonymous insider reported the company before the general public knew about it. Either that or it would serve as a blacklist for companies who already made one mistake, though it's very unlikely to see them make 2 (and in Sony's case, people are still using PlayStation Network anyway).
Nice to see computer professionals practice what they preach, both in terms of writing systems that don't store plaintext passwords and using passwords that don't suck.'
Very OT, but why in God's name do some people/countries feel it appropriate to use imperial units rather than metric units? The reasons are the same - historical usage and inertia against change.
I'm grateful that some countries swap periods and commas relative to the US when writing numbers. It got me a discount on a calculator!
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.
For an organization like IEEE that pushes for professional codes of ethics & quality, certification, etc., it is remarkable how derelict they are in providing even basic security for their users' passwords.
It's a horrible solution. Just store them hashed on the server end, and make a secure connection. I would argue that more browsers support SSL than JavaScript...
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.
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.
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 tops.
The only passwords you won't have plaintexted are those so complex you know the user doesn't reuse them anyway.
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 password strings aren't random nor usually particularly long. Just saying.
You may want to read the last phrase of my comment.
> I find "high-end graphic card (~$500) can compute 10 billion md5 hashes per second" a bit unbelievable
And yet those are the numbers oclhashcat lite publishes for 0.10 on a stock Radeon HD6990 (10886.3M c/s): http://hashcat.net/oclhashcat-lite/
> Yes I realise that md5'ed password strings aren't random
Which is the whole point, and the knowledge the tools I mentioned use: https://community.qualys.com/blogs/securitylabs/2012/06/08/l... (note: the article is about sha1 hashes — which are about 3 times as expensive to compute as md5 — and is done on an older CPU, not GPU-assisted hashing)
You're carefully excision of the end of my "a bit unbelievable" comment misrepresented what I was saying and the manner in which I was saying it:
"a bit unbelievable [but that's progress for ya]"
In case you're comprehension is masked in some way the meaning of this is "it's hard to believe that this is possible [with such stock hardware] but I recognise that technological progress has brought us to a point where this is possible; tech progress can surprise one in this sort of manner" - obviously I felt that such verbosity wasn't required.
masklinn was very clear about the difference between an ivory tower example (yours) and the reality of user passwords. It appears you have missed his point.
>an ivory tower example (yours) and the reality of user passwords //
So you don't think that 'md5 is only as difficult to read as plaintext is actually hyperbole'?
If this is the case then surely someone has a plaintext for the hash I wrote - how much more real can one get. It's a simple English language password.
I can't get it for you because I have a single laptop at my disposal. However, any meagerly funded criminal enterprise which can front a few tens of thousands of dollars could tell you the answer quite easily.
It is not reliable cryptography, and if you provide an incentive to reverse that hash (rather than merely challenging people who have better things to do) then it will be reversed. When it comes to the type of enterprise which cracks systems for profit, it is as good as plaintext.
I don't doubt it could be reversed relatively easily. It doesn't appear to be in the online rainbow tables I tried. But having to look something up, have domain knowledge, making multiple computations, program a parallelised attack using GPUs or however one approaches such a problem I still contend it's significantly (though not greatly) better than plaintext.
You're fundamentally misunderstanding the problem domain.
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.
>"7,000 years divided by 100,000 hashes is 25.55 days." //
This only works if hash reversal costs the same as hash calculation. I think you've made an error.
Brute force in hash terms doesn't mean a "search" it means you take a string, hash it and see if the hash matches. That's the brute part, no grace.
The 7000 years figure is clearly vastly inflated what's needed for passwords in the wild but I'm merely countering the contention that 'md5 is as good as plaintext'.
I note that despite it apparently only taking seconds to reverse my short string that no one has posted the plaintext yet. This doesn't look like it is as easy to read as plaintext.
I'm not at all claiming md5 is good security - just suggesting that the claim that md5 is equivalent to plaintext is hyperbole.
The easy way to show that I'm wrong is to post the plaintext of that hash.
> Brute force in hash terms doesn't mean a "search" it means you take a string, hash it and see if the hash matches.
A) That is a search, and B) I know this. You are still fundamentally misunderstanding the problem domain. We don't care about a hash. We care about 100,000 hashes. You don't need to brute force every single hash from scratch, you simply have to take a string, hash it, and see if that hash is present in the table of 100,000 hashes.
> I note that despite it apparently only taking seconds to reverse
No one claimed that, you inferred it based on a fundamental misunderstanding of the problem domain.
Ha ha. Not really. You're not searching for the plaintext that produces a hash. You're producing hashes irrespective of the result and then matching. IMO the term search would only truly apply if you were reversing the hash mathematically - you'd start with the hash and perform a non-complex operation to find the plaintext.
Instead one searches across hashes after compiling a correspondence table, not across plaintexts. I suppose it's a subtle distinction; largely irrelevant to my contention.
>you inferred it based on a fundamental misunderstanding of the problem domain //
I did not infer it. It was implied. For example,
emidln: "md5 passwords lists are plaintext for modern hardware"
So yes, I suppose adding on a few seconds for plaintext recovery was unfair of me, based on a comment like this I should have said "I note that despite just having to read it back almost as quickly as plaintext ...".
WRT the problem domain. You're discussing an entirely different issue to that which I raised. The start point is simply this:
>"MD5 is an utterly terrible password hash. It's just about as bad as plaintext." //
That is the pertinent problem domain for my comment. I even went to efforts to emphasise that beyond that atomic claim I was recognising the paucity of md5 for real world password hashing - I don't think one can have used Rainbow tables and not realised that point. Are you really contending still that md5 is almost equivalent to plaintext in terms of string discovery and that there is no exaggeration in that.
If the IEEE logs were released with md5 hashed passcodes then other than trivial recognisable cases like 2867-whatever-it-is then one at least has to do work to recover the plaintext.
Aside: I'm intrigued why you created a separate account just to press this position.
The question of password hashing does not concern a password, it concerns passwords. This is a textbook case of being unable to see the forest for the trees. I'm actually astounded by how closely the idiom matches this case.
A simple MD5 hash is "about as bad as plaintext" because the vast majority of passwords will be trivially cracked if it's used, not because any one password will be cracked in a trivial timeframe.
masklinn was speaking against this background. You've created a whole other background that just isn't relevant to the real world issue of password hashing.
> Aside: I'm intrigued why you created a separate account just to press this position.
I created an account so I'd have one to respond to your comment with. The choice of name does not mean it's specific to this discussion, it was simply inspired by it. Again, you focus on an individual detail to the detriment of the big picture.
>Again, you focus on an individual detail to the detriment of the big picture. //
Ostensibly the difference here is that you're looking from the administrative side (it appears) and I'm looking from the user's side.
As for "again". Surely using your regular account makes for a bigger picture as I could see where you're coming from, your general demeanour, your desire to argue incessantly around the point whilst not broaching the point itself, that sort of thing. From your side the choice of name as specific may well be "the big picture" but from anyone else reading the discussion you've removed a lot of out-of-band information that could be pertinent. Which to be honest makes me chuckle as you accuse me, probably rightly in this instance, of narrow focus.
>A simple MD5 hash is "about as bad as plaintext" because the vast majority of passwords will be trivially cracked if it's used //
With plaintext all passwords will be "cracked" in zero time. With MD5 good passwords will be expensive to crack. ROT-13 is about as bad as plaintext. MD5 IMO is better to a point that this claim was exaggeration.
So we'll go straight to the rub - you disagree that there was any exaggeration in that initial statement?
>proper password storage practices mean your passwords are far less likely to be compromised //
Indeed and considering I'm using 20 char mixed passkeys if they're hashed with md5 then they'll take zillions of times longer to reveal than plaintext ... oh wait, no they won't because plaintext is about as bad as plaintext - and you appear to believe that is from any perspective ...
So go on, 3 days must be plenty of time to read something that's about as bad as plaintext at remaining unread.
>You assume much, but know little. //
There is nothing certain, not even this. However pyrhonic absolutism gives sway to pragmatism in general conversation.
So, what, never post on HN, create a new account for each thread, enter comments direct to the db using a morse key ... what? I'd hardly call the assumption that you had an account that you used in the normal way to be massive.
md5 passwords lists are plaintext for modern hardware. Well, not exactly plaintext, since you might end up needing to search a couple collisions that also work, but in terms of repurposing the information to attack another system, it's extremely close to plaintext.
From the article it doesn't sounds like it was anything to do with the db.
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.
I have been a member of the IEEE, and a volunteer on one of their committees, as well as working in the association world in DC.
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.
md5 is not really much better than plain text (I imagine a few Amazon GPU instances could crack most of the md5 hashes very quickly). bcrypt is the way forward in most cases.
Because it's not that important. In most cases what someone could do with my account is to view articles I have paid for, either piecemeal or as a subscription. It's much more in their interest than my interest to keep that private.
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.
> 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.
"Most users reuse the same password again and again and again. Having their password leaked"
Yes it is generally accepted that many users reuse the same password on different sites. But that is a separate issue and really has nothing to do with what has happened here or why proper security should obviously be followed. Not disagreeing with that.
But I disagree with the fact that since the user does the wrong thing many times, it is the responsibility of the site operator to assume that in the building of their product (in the way this issue is being discussed). If it is, where are all the warnings on any site saying "make sure not to give us a password you use anywhere else". (I've rarely seen any warning like that, have you?)
Of course this is all a matter of degree. There are many cases where you have to prevent users from their folly. True. My question is simply while there are many ways that sites try to enforce correct password behavior, I've yet to see (meaning if it exists I haven't really noticed it whereas I've notice other password thoughts) one that informs people to make sure the password they use is unique to their site AND the other typical restrictions (length, mixed case etc.)
> Yes it is generally accepted that many users reuse the same password on different sites. But that is a separate issue
No. That's the one and whole reason why you're supposed to one-way encrypt passwords with a suitable hash: protecting the shared secret.
> But I disagree
So what?
> If it is, where are all the warnings on any site saying "make sure not to give us a password you use anywhere else". (I've rarely seen any warning like that, have you?)
Yes, I have. These warnings don't actually add to anything as they're not followed, and impossible to get followed without making the system so cumbersome it's unusable. Apart from using 2-factor auth. Which is an other "responsibility of the site operator" which I guess you wouldn't want foisted upon him as you seem to believe site operators are and should be irresponsible.
> one that informs people to make sure the password they use is unique to their site
A suggestion which will go instantly ignored by 99% of the users (on average, technical sites will probably be lower). The single % left already don't reuse passwords.
You seem unfamiliar with the specific case. It wasn't the user database that was compromised.
It was plainly obvious to any user of IEEE that they were storing your password in clear text. Because they would, y'know, mail it to you. And the mail would have live hyperlinks to access your account, which generally means GET requests.
Then please don't bring it up, i.e., say things like "if the user database is compromised, you can safely assume all of the site is".
And nobody every took issue with that?
Maybe they did, maybe they didn't. IEEE members are probably slightly more informed than your random AOL user. There are plenty of mail managers out there that mail you your password automatically every month.
A password leak is one of several ways in which a user database can be considered compromised. Beside the fact that every leaked user had access to every other leaked user's database record, which is a huge breach in itself, how do you know that no administrative credentials were leaked?
The user database was compromised in a major way, even if nobody got root.
Sure, you can do all of these things, and being able to view IEEE papers is not exactly the worst of problems. Now please let me know if I'm incorrect (and I hope I am), but it appears that in addition to viewing research papers your IEEE Web Account also lets you modify your @ieee.org e-mail alias account (if they have set one up; if not, they can create one) [1].
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.
any decent corporate IT dept make sure you don't by forcing often password changes and having quite secure rules for length and charactes in a password. My corporate IT force quarterly password changes for VPN, NIS and SSO, which all must be different, all must be 8+ characters, all must have mix of upper and lower and numerics. They also store the hash of all previous passwords to prevent users from recycling.
So I think the onus of responsibility lies with corp IT and not HR.
Forcing people to change their password is one of the most annoying and ineffectual things you can do. It is completely useless to change a perfectly good password when it has not been comprised. And since most humans have trouble memorizing complicated passwords, the net result will be much simpler passwords, or ones that get written down.
There's no technical solution to this problem. In the end it comes down to making people actually memorize pseudorandom passwords. As long as there's no shoulder surfing or keyloggers, you can keep such a password for years.
You know how people that work at your company remember their passwords after having to change them so often and comply with so many rules? They write them down on post it notes that they leave at their desks.
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.