
Data Breach Reveals 100k IEEE.org Members' Plaintext Passwords - ddol
http://ieeelog.com/
======
shanemhansen
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.

~~~
runn1ng
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"?

~~~
bigiain
And, upon re-reading my other answer and noticing it came out far snarkier on
screen than it did in my head… Sorry 'bout that…

<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)

~~~
wiradikusuma
For the sake of completion:

[http://en.wikipedia.org/wiki/Server_Name_Indication#No_suppo...](http://en.wikipedia.org/wiki/Server_Name_Indication#No_support)

------
kibwen
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!

------
typicalrunt
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.

~~~
freehunter
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.

~~~
emidln
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".

------
creat0
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.

How many commenters actually read the article?

------
danso
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.

------
andrewcooke
"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).

~~~
freehunter
People have been threatened with legal action for discovering vulnerabilities
before.

------
fromhet
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.

------
engtech
I think it's time for web browsers to step up and start showing a visual
indication for websites that store passwords in plaintext.

~~~
wesley
How would a browser ever know this?

~~~
diminoten
Probably the same way they know which sites are likely to contain malware or
be involved in phishing scams: user reports.

~~~
Tipzntrix
Yep. <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.

------
makmanalp
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.'

</sarcasm>

~~~
eli
The most common password in a giant list of passwords is going to suck sort of
by definition.

~~~
makmanalp
Actually, you're right: only 1% using (1234...) ain't half bad.

------
CamperBob2
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?

~~~
gibybo
Maybe those people/countries think the same about people using the comma as a
thousands separator instead of a decimal?

~~~
CamperBob2
The 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...](http://www.jstor.org/discover/10.2307/2298362?uid=3739960&uid=2129&uid=2&uid=70&uid=4&uid=3739256&sid=21101250798947)
)

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.

------
astangl
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.

------
trekkin
Properly 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
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...

~~~
pjscott
Agreed. 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.

------
m8urn
Its probably not a great idea admitting to downloading all that data.

------
diminoten
Anyone have the file?

~~~
DanBC
I'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>)

------
PythonDeveloper
How is that this esteemed organization of technical people doesn't know how to
md5 passwords before storing them in the database?

~~~
danielweber
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.

~~~
masklinn
> 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.

~~~
larrys
"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.)

~~~
masklinn
> 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.

