Wow. This is extremely stupid.
-------- Original Message --------
Subject: [cryptography] Data breach at IEEE.org: 100k plaintext passwords.
Date: Tue, 25 Sep 2012 13:39:34 -0400
From: Jeffrey Walton
Reply-To: noloader@gmail.com
To: Randombit List
In case anyone on the list might be affected... [Please note: I am not
the "I' in the text below]
http://ieeelog.com
IEEE and the log story
IEEE (Institute of Electrical and Electronics Engineers) is renowned
as one of the world-leading organizations in standard development and
the promotion of scientific and educational development within the
Electrical, Electronics, Communications, Computer Engineering,
Computer Science and related fields. The organization has more than
415,000 members all over the world, almost half of them in the United
States [1].
By the nature of the organization, IEEE members are highly specialised
individuals, many of them working in critical industry, governmental
and military projects. Furthermore, it would be reasonable to assume,
that an organization publishing leading security-focused publications
[2], would value the privacy of its members, and be proactive in
keeping their data secure.
Due to several undoubtedly grave mistakes, the ieee.org account
username and plaintext password of around 100,000 IEEE members were
publicly available on the IEEE FTP server for at least one month.
Furthermore, all the actions these users performed on the ieee.org
website were also available. Separately, spectrum.ieee.org visitor
activity is also publicly available.
The simplest and most important mistake on the part of the IEEE web
administrators was that they failed to restrict access to their
webserver logs for both ieee.org and spectrum.ieee.org allowing these
to be viewed by anyone going to the address
ftp://ftp.ieee.org/uploads/akamai/ (closed on September 24 around
13:00 UTC, after I reported it). On these logs, as is the norm, every
web request was recorded (more than 376 million HTTP requests in
total). Web server logs should never be publicly available, since they
usually contain information that can be used to identify users
(sometimes even after the log was anonymized as in the "AOL incident"
[3]). However, this case is much worse, since 411.308 of the log
entries contain both usernames and passwords. Out of these, there seem
to be 99.979 unique usernames.
If leaving an FTP directory containing 100GB of logs publicly open
could be a simple mistake in setting access permissions, keeping both
usernames and passwords in plaintext is much more troublesome. Keeping
a salted cryptographic hash of the password is considered best
practice, since it would mitigate exactly such an access permission
mistake. Also, keeping passwords in logs is inherently insecure,
especially plaintext passwords, since any employee with access to logs
(for the purpose of analysis, monitoring or intrusion detection) could
pose a threat to the privacy of users.
Log analysis
It is certainly unfortunate this information was leaked out, and who
knows who got it before it got fixed. Maybe there are access logs for
the FTP so the damage can be assessed. Anyway, the affected users will
probably have to be informed, since it is my understanding that the
law requires it. In Europe there is Article 4 of the Directive on
privacy and electronic communications (Directive 2002/58/EC) and its
amendment (Directive 2009/136/EC). In the US, 46 states seem to have
similar requirements [4].
While the cause of the data breach has been solved, one must point out
the value of this dataset from a research perspective. It is rare that
researchers gain access to such rich datasets. Various ethical and
privacy-related considerations must be evaluated before such datasets
can be publicly released. Deciding on how to anonymize the data is no
easy challenge. Simply excluding any information making users directly
identifiable is not enough, as past dataset releases have shown that
some users can still be pinpointed. This resulted in lawsuits in the
case of Netflix [5] and AOL [6], or the withdrawal of the data, like
in the recent Wikipedia case [7]. For this reason, companies such as
Google prefer to keep such data for study by internal researchers and
do not release it to the public [3]. Furthermore, some companies
release data to a trusted researcher with the condition to remain
anonymous, like an unnamed European mobile phone operator did for
Albert-LC!szlC3 BarabC!si [8]. This means academic researchers working in
such fields as Information Retrieval have limited access to fresh
real-world data, being at a disadvantage to their industrial
counterparts.
For these reasons, I cannot not give in to the urge to perform a basic
analysis of this serendipitously acquired data, although I acknowledge
this might be ethically dubious. However, I did not, and plan not to
release the raw log data to anyone else.
Data overview
Log data time span: 01/Aug/2012:20:46:28 +0000b to 18/Sep/2012:08:47:17
+0000
Total number of log entries: 376.021.496
log entries for ieee.org: 301.319.566
log entries for spectrum.ieee.org: 74.701.930
log entries with password details: 411.308 (of which 17.157 are
password reset requests and have no username field)
...
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
