WineHQ database compromised
On the one hand, we saw no evidence of harm to any database. We saw no evidence of any attempt to change the database (and candidly, using the real appdb or bugzilla is the easy way to change the database). Unfortunately, the attackers were able to download the full login database for both the appdb and bugzilla. This means that they have all of those emails, as well as the passwords. The passwords are stored encrypted, but with enough effort and depending on the quality of the password, they can be cracked." Anybody who has reused a password stored there probably wants to make some changes fairly soon.
Posted Oct 12, 2011 0:14 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
On completely unrelated note, does LWN store credit card numbers?
Posted Oct 12, 2011 0:25 UTC (Wed)
by jake (editor, #205)
[Link] (9 responses)
No we do not (thankfully) ... we transmit them to the credit card processor and are done with them at that point. For monthly subscriptions, we get back a magic cookie that can be used to charge the same account, but we don't keep credit card information.
We sleep *much* easier that way ...
jake
Posted Oct 12, 2011 0:51 UTC (Wed)
by aaron (guest, #282)
[Link] (5 responses)
BTW, as one of many sysadmins handling PCI compliance (in addition to our usual duties), can you comment on how the process worked for you?
There's a good talk coming up in Seattle this Thursday, on audit logging on Linux for compliance. Apparently, it's not as trivial as one might hope.
Posted Oct 12, 2011 1:01 UTC (Wed)
by corbet (editor, #1)
[Link] (4 responses)
The penalty for not being certified was a crushing $25/month; there came a point where we realized it just wasn't worth the trouble.
$25/month also made it clear just how important the credit card system thought PCI compliance certification was.
Now we don't let credit card numbers pass through the site at all, and things are a lot easier.
Posted Oct 12, 2011 9:10 UTC (Wed)
by njwhite (guest, #51848)
[Link]
Yep, that sounds about our experience, too. I ended up writing a script to scrape info of patched CVE issues from our distribution's website and emailing the PCI people a list of links to "prove" that said patches have been applied.
It's all, I think, so that the card processor can push the liability for any losses away from them.
Posted Oct 12, 2011 16:44 UTC (Wed)
by aaron (guest, #282)
[Link]
I assume that was the ASV*, not the processor. Ours simply needed to be told the the CVEs were patched (which Debian & Ubuntu are good at doing, and more importantly, documenting.) It was a good impetus to turn off the detailed version info on our daemons. <smirk>Information leak, y'know.</smirk>
Interestingly, an SSL cert. company that recently suffered security problems also happens to be an ASV.
Posted Oct 12, 2011 21:59 UTC (Wed)
by rickmoen (subscriber, #6943)
[Link]
Rick Moen
Posted Oct 13, 2011 4:05 UTC (Thu)
by k8to (guest, #15413)
[Link]
It's all too familiar to hear from customers (from auditors) that their scan-thing found a red item. Usually these red items represent bugs in the scanners, but they don't care (neither the auditor, nor the customers).
Fortunately our software doesn't have to actually pass the test software (it doesn't touch the card stream). So I point out some of the clauses of PCI compliance that say they don't have to care, and suddenly they're happy.
Sigh.
Posted Oct 12, 2011 6:19 UTC (Wed)
by Felix.Braun (guest, #3032)
[Link]
Posted Oct 12, 2011 17:27 UTC (Wed)
by quotemstr (subscriber, #45331)
[Link] (1 responses)
Posted Oct 12, 2011 18:13 UTC (Wed)
by jake (editor, #205)
[Link]
bcrypt hashing ... see http://lwn.net/Articles/433905/ for a few more details ...
jake
Posted Oct 12, 2011 0:55 UTC (Wed)
by corbet (editor, #1)
[Link]
Posted Oct 12, 2011 8:59 UTC (Wed)
by epa (subscriber, #39769)
[Link] (16 responses)
What can web browsers do to make the most obvious way be a better way? Could the browser hash the passwords itself together with the site name, so while the user types the password into the login field (or 'change password' field), the site sees a hashed value which is specific to that site? Then at least if the plaintext password database is disclosed, it doesn't give any way to exploit that user's account on other sites.
Posted Oct 12, 2011 9:21 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
http://crypto.stanford.edu/PwdHash/ or https://www.pwdhash.com/
I use them for all my low security stuff where I "should" have separate passwords but can't be bothered to memorise them. You should definitely still practice password hygiene by not re-using the password for important stuff, since reversing the pwdhash hash (after such a site inevitably lets the plaintext passwords out the door) is merely difficult, not close to impossible for most people's passwords.
I keep expecting Firefox to just build this feature into the browser, but it seems it isn't happening.
Where you have any site-design influence you should try to avoid passwords anyway. OpenID, or even one of the nasty proprietary "connect" solutions are better from a security point of view by removing the password database from the unrelated application software.
Posted Oct 12, 2011 9:41 UTC (Wed)
by bjartur (guest, #67801)
[Link] (2 responses)
Disclaimer: I unsubscribed from the list minutes ago.
Posted Oct 12, 2011 12:13 UTC (Wed)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Oct 12, 2011 12:46 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link]
There are lots of ways this stuff could be smarter or better, but PwdHash does seem like a pretty good stop gap for the foreseeable future.
Posted Oct 13, 2011 4:58 UTC (Thu)
by k8to (guest, #15413)
[Link]
The stored values are hashes, so the attacker got the hashes. WineHQ is just being realistic that crack will recover many of them soon enough, and is warning users to alter their passwords elsewhere.
I am very happy that I keep the passwords I use for each site in an easily reviewed form, so I could quickly determine that there is no overlap.
Realistically though, I would rather not have ever had a password or account at all for their bugzilla. I had to file a bug, and I'd have rather just emailed it in, possibly with a mailback to verify validity. The fact that bugzilla is broken for this common workflow is a bug I filed against bugzilla.
Posted Oct 12, 2011 9:25 UTC (Wed)
by mordae (guest, #54701)
[Link] (6 responses)
If this gets implemented properly and browsers inform user that they are sending over raw password, sites might actually implement that.
Posted Oct 12, 2011 9:43 UTC (Wed)
by bjartur (guest, #67801)
[Link] (3 responses)
Posted Oct 12, 2011 12:08 UTC (Wed)
by mordae (guest, #54701)
[Link]
Posted Oct 12, 2011 20:18 UTC (Wed)
by HenrikH (subscriber, #31152)
[Link] (1 responses)
Posted Oct 13, 2011 15:59 UTC (Thu)
by beect (guest, #71486)
[Link]
Posted Oct 12, 2011 12:14 UTC (Wed)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Oct 12, 2011 12:56 UTC (Wed)
by iq-0 (subscriber, #36655)
[Link]
But a more tightly coupled approach with you password manager can improve a bit on this scheme (probably only really sensible when using firefox sync if you work on more than 1 computer) by adding another piece of random data that is stored in you password manager (still regardless of whether it would include you password itself).
Also they could improve on it by using their crypto backend especially when one has a hardware cryptoki. Most browsers already support this for logging in using client certificates. This could be used to sign the username/site pair with your key and use that as a password. Effectively limiting the use to 1 site. Though you'd still want to add state to the browser, otherwise you'd be unable to generate a distinct password for a site once it has been restored after hack and the attacker could still access the site as you (or you'd have to create a new username, but that would be a stupid restriction). That state by the way doesn't have to be secure, you could just put it on some publicly readable site (eg. in your facebook profile description, than it would at least be put to good use :-D)
Posted Oct 12, 2011 14:40 UTC (Wed)
by endecotp (guest, #36428)
[Link] (3 responses)
A good guide is
- Has a "email password reminder" button => passwords not hashed
(This isn't perfect, but I bet it's very close.)
Posted Oct 12, 2011 17:31 UTC (Wed)
by quotemstr (subscriber, #45331)
[Link] (2 responses)
Posted Oct 13, 2011 20:04 UTC (Thu)
by Cato (guest, #7643)
[Link]
Really the best solution is two-factor authentication - supplement weak and easily stolen passwords with something you have (like a mobile phone or a landline).
Posted Oct 15, 2011 21:26 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
So, not completely awful, but pretty bad. Not once during the long thread of comments on Bugzilla does anybody think that maybe they should see if this critical security work has already been done, properly, by someone who actually knows what they're doing... Wheel? What's that, this is my rotating movement device.
WineHQ database compromised
WineHQ database compromised
WineHQ database compromised
With our previous processor, the compliance process turned out to be such a silly hassle that we eventually gave up on it. They kept screaming, for example, that our version of SSH had known vulnerabilities - even though the distributor had long since patched those vulnerabilities out. All that mattered was The Checklist, which had little to do with how secure we actually were.
PCI compliance
PCI compliance
> SSH had known vulnerabilities - even though the distributor had long since patched those
> vulnerabilities out. All that mattered was The Checklist, which had little to do with how
> secure we actually were.
PCI compliance
They kept screaming, for example, that our version of SSH had known vulnerabilities - even though the distributor had long since patched those vulnerabilities out.
* ASV: Approved Scanning Vendor - a company approved by the PCI Security Standards Council to perform very basic (Nessus-style) vulnerability scans. Scans are required quarterly. Subscriptions aren't cheap.
PCI compliance
rick@linuxmafia.com
PCI compliance
WineHQ database compromised
WineHQ database compromised
WineHQ database compromised
As Jake already said, we don't store any credit card numbers at all. It is, in fact, even better than that; our "buy now" form submits directly to the processor, so the numbers don't pass through the site at all. Among other things, that eliminates much of the PCI compliance hassle.
Credit card numbers
Storing passwords
PwdHash
But note that this can't be done by default, as it would break the killer-feature of HTTP and cookie authentication: allowing you to walk to any public terminal and start reading lwn. Terribly insecure, considering how easy it is to log keypresses on public terminals, but convenient.
There was a discussion on the WHATWG ML about allowing sites to request client-side hashing of passwords with a standardized on hashing algorithm, or in other words, to allow sites to tell your friend's user agent how to hash your password. Maybe you'd lake to participate in the discussion?
PwdHash
PwdHash
But note that this can't be done by default, as it would break the killer-feature of HTTP and cookie authentication: allowing you to walk to any public terminal and start reading lwn.
Why not? The hash is based on the password entered and the domain name of the site - no information specific to the local machine is used. So it would give the same hash no matter what computer you sat down at.
PwdHash
PwdHash
Storing passwords
Storing passwords
That has actually been implemented in most major HTTP clients. Does lwn support it?
Storing passwords
Storing passwords
Storing passwords
Storing passwords
Just have site return an unique ID in HTTP header or meta tag
I was hoping for something that browsers could implement immediately without any co-operation from sites, since it's clear that a large number of websites won't put any effort into improving password security.
Storing passwords
This way you have a predictable salt which will still help against plain reuse of your password on other sites and against rainbowtable attacks, but which would be relatively easily thwarted with a good password cracker.
And you have a random salt which would effectively make it impossible to do guess safe for a brute-force attack and would thus give additional protection by making it almost impossible to guess what the password is that you memorize.
And lastly, even if they knew your password, they'd still be unable to use it without the random data stored in your browser.
Storing passwords
> the passwords or not.
- Has a "reset password" button => passwords hashed
Too often, the "passwords hashed" case boils down to a single, unsalted iteration of MD5. Given the availability of large rainbow tables, this password storage approach is scarcely better than plain text. While hashing passwords is a good first step, the naive approach is insufficient. It's important to do it right.
Storing passwords
phpass
Storing passwords