11 ms·
Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords
- PythonDeveloper 14y agoHow is that this esteemed organization of technical people doesn't know how to md5 passwords before storing them in the database?
- gaius 14y agoBecause it's only a website, not REAL engineering! Let the intern do it!
- valisystem 14y agoMaybe they did that right after writing it clear text in http logs stored in publicly accessible files.
- njr123 14y agoFrom 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.
- fredley 14y agoMD5 is not suitable either. The illusion of security is almost worse than no security.
- stordoff 14y agomd5 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.
- danielweber 14y agoBecause 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.
- masklinn 14y ago> Because it's not that important. 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.
- danielweber 14y agoYou 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.
- masklinn 14y ago> You seem unfamiliar with the specific case. It wasn't the user database that was compromised. Which isn't really relevant. A password leak is a password leak, whatever its source is. > It was plainly obvious to any user of IEEE that they were storing your password in clear text And nobody every took issue with that? > And the mail would have live hyperlinks to access your account, which generally means GET requests. That doesn't mean anything, the hyperlink could have contained a nonce allowing log-in.
- danielweber 14y agoWhich isn't really relevant. 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.
- masklinn 14y ago> know how to md5 passwords 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.
- pbhjpbhj 14y ago>It's just about as bad as plaintext. // Hyperbole is just about as bad as murder.
- emidln 14y agomd5 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.
- masklinn 14y ago> 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 tops. The only passwords you won't have plaintexted are those so complex you know the user doesn't reuse them anyway.
- pbhjpbhj 14y agoReally? 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 password strings aren't random nor usually particularly long. Just saying.
- jeremyt 14y agoI 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.
- ancat 14y agoinb4 "bcrypt bcrypt bcrypt bcrypt bcrypt bcrypt bcrypt bcrypt"
- engtech 14y agoI think it's time for web browsers to step up and start showing a visual indication for websites that store passwords in plaintext.
- wesley 14y agoHow would a browser ever know this?
- diminoten 14y agoProbably the same way they know which sites are likely to contain malware or be involved in phishing scams: user reports.
- Tipzntrix 14y agoYep. http://news.ycombinator.com/item?id=4555083 http://news.ycombinator.com/item?id=4555083 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.
- nathan_long 14y agoOf 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.
- masklinn 14y agoAnd... how could they know exactly?
- engtech 14y agoweb browsers are doing this for malware / fraud sites. see other comments on parent for citations.
- typicalrunt 14y agoWhat 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.
- danielweber 14y agoIn general, you may expect that even if GETs are fully logged, POSTs are not. You can check this on your own when you renew.
- freehunter 14y agoIf 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.
- emidln 14y agoIf they don't do the processing themselves, they can fill out the self questionaire, which basically amounts to "pay the damn application fee already".
- m8urn 14y agoIts probably not a great idea admitting to downloading all that data.
- diminoten 14y agoAnyone have the file?
- DanBC 14y agoI'd be interested in it too. 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 http://www.ieee-security.org/TC/SP2012/papers/4681a538.pdf)
- danso 14y agoSorry, 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.
- shanemhansen 14y agoI 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.
- snprbob86 14y agoI 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.
- fmavituna 14y agod) To not keep 100K users' passwords in a public FTP server :)
- kree10 14y agoI'd take that further. Is there any good reason for anyone to run an FTP server (public or otherwise) in 2012?
- jimhefferon 14y agoHow do you dir on http?
- andrewcooke 14y ago"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/ http://www.dragusin.ro/; seems like an academic rather than a hacker. still, that seems like an odd thing to be uncertain about).
- freehunter 14y agoPeople have been threatened with legal action for discovering vulnerabilities before.
- deleted 14y ago[deleted]
- tisme 14y agoThis may have been on his mind: http://www.iovation.com/blog/dutch-hacker-extradited-from-romania-charged-with-credit-card-fraud http://www.iovation.com/blog/dutch-hacker-extradited-from-ro...
- kibwen 14y agoThe 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!
- makmanalp 14y agoNice 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.' </sarcasm>
- trekkin 14y agoProperly hashing/salting passwords on the client (in JavaScript) is more or less a must now. Client-side encryption is the next logical step. Although not perfect, it is better than storing plaintext data on the server.
- vegardx 14y agoIt'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...
- pjscott 14y agoAgreed. I see three possibilities: 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.
- CamperBob2 14y agoOT, 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?
- gibybo 14y agoMaybe those people/countries think the same about people using the comma as a thousands separator instead of a decimal?
- CamperBob2 14y agoThe trouble is, the period already means something very different. This has been the case since at least the 15th century. ( http://www.jstor.org/discover/10.2307/2298362?uid=3739960&uid=2129&uid=2&uid=70&uid=4&uid=3739256&sid=21101250798947 http://www.jstor.org/discover/10.2307/2298362?uid=3739960... ) 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.
- tb 14y agoVery 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.
- tzs 14y agoI'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.
- fromhet 14y agoThis 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.
- creat0 14y agoAs 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. How many commenters actually read the article?
- astangl 14y agoFor 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.