The Dropbox SNAFU
Nearly 70 million password hashes and emails were exposed
It's not good. (BTW, Silicon Republic, his name is "Troy Hunt", not "Troy Hunter".)
The issue here is not just the size of the breach, which is historic, but also the length of time it went either undetected or unannounced: four years. For four years these email addresses and hashed passwords have been floating around God knows where. SilRep claims (I can find no sourcing) that in 2012 Dropbox sideband contacted a group of users with credentials exposed in other breaches, but did not reveal the extent of the problem (if they in fact knew).
Motherboard (second link) broke the story after obtaining a portion of the payload from a contact in the (ahem) "database trading community". This came just days after Dropbox forced a mass password change for presumably similar reasons. The question remains open whether somebody had been sitting on these out in the darkweb somewhere, or whether Motherboard was motivated to go find something after Dropbox made its announcement.
The salt is apparently safe for the SHA1s
Hunt confirms the breach. He also adds that the passwords were unequally protected. Roughly half were salted and hashed with SHA1; the rest were salted and hashed with bcrypt. The bcrypt salts were exposed, and the SHA1 salts were not (at least not in the material Motherboard and Hunt got their hands on). As he points out, a salted SHA1 without the salt available (and, hopefully, also without it being predictable) is not terribly useful to an attacker. That said, an email address is always useful, so there's that.
This seems to have been because of password reuse
And now for the fun part: blame. That's right: a DropBox employee reused a password that he had used on… LinkedIn. On the plus side, DropBox claims it now requires password managers and 2FA on all internal systems (you do too, right?).
Starting a new job next week
I'm starting the blog over
So, as a bit of housekeeping, I intend for the scope of this blog to be whatever thoughts I come up with on systems administration at my new job. I have had a pendulum over the years between "put everything into one blog" and "break out different blogs for different subjects", and it's swung more to the latter right now.
I would like to update this regularly
I'm putting this out there to try to help me commit to this: I want to update this daily. I'm using orgmode both to keep day-to-day notes and to write this blog (with some help from nikola) which I hope will help me keep this integrated into my workflow.
On that note, I'm doing a half-hearted "live in emacs" challenge to myself. The new workplace uses hipchat (and of course email) so I'll be testing the various ways emacs can integrate those activities. For hipchat I'll be looking at both jabber.el and ERC with the IRC gateway. For email I've gotten used to gnus, but I may just use fetchmail and rmail for work email for better notifications (gnus's lack of good notifications is a problem I keep trying to fix).
I will probably destroy it eventually
As always, don't expect anything on a blog of mine to stay up for any particular amount of time.
My new job is Linux-heavy
On to the employment news! I'll be starting on the 6th at a tech company in Reston. I'm looking forward to it for several reasons. It's employment, firstly. Secondly, a friend of mine works nearby. And finally the work itself seems interesting: it's largely management of Linux servers.
It's a good step
This is a good career step for me because I was worried about being dragged back in to the vortex of managing Windows systems. This is an established company with a pretty good reputation in the field, so this will be a step up. It's largely an engineering firm, which also interests me.
It's also a commute
Now, the downside: it's in Reston (actually I think technically in Herndon). We're going to have to get a car, realistically, but until then I can do the Metro-to-bus dance which should take about an hour or a little more each direction. C'est la vie.
The servers are apparently mostly CentOS, which is fine. It's mostly 5 and 6, which means systemd won't quite have reared its ugly head yet (obviously that will change pretty quickly, most likely).
And it's a lot of Python
And, in other good news, this is a shop that has pretty much entirely avoided PHP and Ruby. Also Perl, which is a shame because I prefer it to Python. But, this is a good chance to dust off my Python which has lain, python-like, in slumber for a few years.
The founder and I talked about Forth and Lisp in the interview, which was also a good sign. I'm a very firm believer in language-agnostic hiring (there's very little to actually learn about any programming language). So, yeah, some Flask is in my future.
It's also a lot of virtualization and containers
It's 2016, so this shouldn't be surprising. The engineers produce turnkey servers for clients, and that involves a lot of virtualization for testing and development. So it's a lot of docker and a lot of Xen or KVM.
I'm not happy with the state of containers right now
I'll be talking about this more, but I'm not happy with the state of containers right now. Docker doesn't have any specific problems with its engineering (at least no more than anything else does), but it leads to some bad habits, like 4 different versions of Python being used in the same project. Docker makes that less painful, but is that a good thing?
As I said in my interview, "Docker is the best-available tourniquet for the self-inflicted wound of poor stack management". But it's hard to avoid.
But the state of virtualization is good
In better news, I like the state of full virtualization right now. Xen is still my favorite (and fortunately it's the default in CentOS), but KVM is really improving. And, better news, there doesn't seem to be any ESXi in this job (not that I particularly dislike ESXi, but this is a good chance to expand to other things).