_phred's comments

A very cursory internet search shows that your history is entirely wrong:

https://agileforall.com/history-of-tdd-as-told-in-quotes/

Djikstra proposed the idea in the 1970s. Rails did not in any way pioneer TDD. They were very vocal about it but “[stood] on the shoulders of giants.”

Very helpful y’all, thanks! Gonna see if I feel up to tackling the repair (good excuse to buy a reflow setup) and or get in touch with this gentleman. Cheers!

I’ve got two first gen HomePods here which died slightly out of warranty, and AppleCare wanted $300 a piece just to take a look at them. Makes me quite gunshy about spending yet another $300 on a product which may not last more than 2-3 years.

Hmm, yes, I think I conflated the asymmetric vs symmetric cases.

Shor's algorithm is very tasty, but when the real world demonstrations at top research facilities are saying, "yes, we factored 21 into 7x3, but WITH ENTANGLEMENT"[1] it makes me think that scaling to RSA-size prime factors is still a good way off.

Listen, the US government is powerful, but building a full scale quantum crypto decoder ring in complete secrecy _decades_ ahead of everyone else? I just don't think so. Maybe I'm a sheep for not wanting to believe the government so powerful and corrupt, but the whole thing sounds like a tin foil fantasy.

I don't doubt they would if they could, though. And they've done as much as they can with present day tech: supercomputers, mass data collection, penetration of target systems, exploiting SSL's many weaknesses, tapping undersea lines, and legally strong-arming perceived threats into giving up their encryption keys. I just don't think we need to get science fiction involved.

[1] http://www.nature.com/nphoton/journal/vaop/ncurrent/full/nph...

See http://en.m.wikipedia.org/wiki/Shor's_algorithm

Ah shoot, you're right. I'm an armchair crypto geek at best.

In any case, you can choose a public key exponent large enough to still make it a hard problem to crack in a reasonable amount of time. Barring some huge vulnerability in RSA that hasn't been discovered in 30 years of public scrutiny, of course.

The best publicly known attacks on RSA reduce the attack time by a few orders of magnitude at best. A functional quantum CPU could reduce that by a few more orders. Your 4096-bit RSA key is still 2^3072 times harder to break, so even with reductions we're still talking about "heat death of the universe" amounts of time to brute force.

RSA has issues but as of yet hasn't yielded entirely to cryptanalysis.

As the article says, it's easier to attack the system and try to get the plaintext, or coerce you into giving up your key through legal means.

Edit: adding a link to Wikipedia's article on post-quantum crypto, it's a good place to start understanding how to answer these type of questions:

http://en.wikipedia.org/wiki/Post-quantum_cryptography

Yes: call/SMS forwarding. It depends on how good your first factor (e.g. password policies) are, and how your reset process works. Getting someone's phone number and setting up call forwarding doesn't require much social engineering savvy to pull off.

http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...

Looks like it's built around KVM (Kernel Virtualization Modules), i.e. "containers", rather than full-blown virtual machine emulation like Xen or VirtualBox/Vagrant.

It appears to be a configuration management / deployment tool for KVM containers. New to me too, gonna dive in and check it out.

Wow, that comment thread... does not lend itself to confidence in their project's security.

It also illustrates a really key point about crypto: because it looks simple (oh, just run the bytes through that function/hash/send them over SSL), people assume that it is simple they know enough to hack together a decently secure system.

At the very least, a healthy respect of crypto theory is called for. In my experience most developers do not have this healthy respect and see crypto as a magic black box that makes data unreadable.

I find attacks on cryptosystems illustrative for the "oh CRAP" moment. Oh CRAP salted hashes are a terrible idea. Oh CRAP you can pad a hash to make a remote system accept "signed" data. The more I learn and the older I get, the more cautious I am.

Hackers built Facebook. They hire hackers. If there's a group that's hardest to pigeonhole in terms of beliefs it's hackers.

The idea that a company composed if hackers could have not a single whistleblower, no single person that objects so strongly that they must speak up regardless of their personal situation is betting against human nature. Nay, hacker nature.

Freedom ain't looking good nowadays, but this is not the vast conspiracy it may seem.

Interesting, thanks!

I have a theory that the accelerometer-linked 3D "layer" effects might make the flat interface more usable in person. As in, the subtle perspective shift would make it obvious that a button is a button, etc. Can you comment on that? Are those effects extended to all of the UI elements?

A lot of API authentication is half-assed, like the examples in the article. "OAuth is hard, roll your own" is a common approach. Even with, e.g., OAuth 2, who's to say that the scheme is completely safe and that your implementation is correct?

As far as API vs. user account, it depends on the loot. An API might let me do more damage faster, or subtly lurk and alter/steal data over time. It might also be harder to detect from the UI, no "last logged in" giveaway.

Also, some API vendors recommend disabling SSL cert validation client side. Even for credit card gateways, unbelievably. Since it's a script talking to a script, no one is going to see the cert problems from a MITM until it's too late.

Right. If the attack vector is "break SSL" I'm going to try some other attacks first. There's an underlying assumption in the question: my app (and everything else hosted on the box) is safe from XSS, CSRF, injections, and other information leakages. Is it really? How do I know for sure?

And who's to say that your forum server (for example) is just as secure? That could be a foothold into your environment too. And let's not forget social manipulation of your staff and users. Maybe I'll just steal the machine in question, or your laptop.

After I try all those avenues, I'm either finding another target or ramping up for a protracted attack on your SSL connections.

If your site attracts this dedicated of an attack, you'd better get that high paid security consultant. ;)

O, cruel fortune! I rue my talent.

So as a sort-of-amusing counterpoint to this article, I know at least one ASV who insists that the only way to mitigate BEAST is to disable all ciphers but RC4. Still scratching my head on that one.

That tool you posted is great, hugely helpful for anyone who has to deal with this stuff.

There's nothing like good old plain text. :)

Nowadays I'm downright spoiled and use org-mode[1] to keep my systems journals. Org files are plain text as well, and org-mode takes care of setting up the tree by date. I can also add a journal entry from anywhere in Emacs with just a couple keystrokes, which makes it incredibly low-friction to use.

Like I said, the most important thing is to TAKE NOTES. Even pen and paper. It's one of Limoncelli's big points in Time Management for System Administrators.

Tooling doesn't really matter, the important part is being able to remember what the heck I did and when I did it. Invaluable for troubleshooting.

[1]: http://orgmode.org

I'm throwing my hat in the ring. I took the author's original post and implemented it as an Ansible playbook in a little less than an hour.

http://practicalops.com/my-first-5-minutes-on-a-server.html

Happy to answer questions about it. :)

Very, very difficult, unless the host relies on a single timesource. Best and common practice is to use 3-4 sources from different organizations in the ISC pool. It also wouldn't surprise me if most implementations of ntpd would have further safeguards about going 40 years back in time; at the very least the skew factor would make the clock change take a longgggg time to happen.

There are much easier attack vectors.

Whoa, your terminal playback thing is pretty neat. Did you use GNU Screen to record the session?