...except when attackers get hold of the (hashed passwords | public key).-f0dder
Understood. But that's kind of a different (Typically SQL code security) issue. A way in is a way in, and once "they" are in... 
-Stoic Joker
Well, yes and no - systems aren't isolated these days. Most people use the same password(s) for multiple accounts. If it's breached (or lured away from you) once, an attacker typically has access to a lot more sites. Keep in mind that most schemes either
1) send password in plaintext (though trough SSL) to verify at the server side, while keeping a (hopefully
) secure hashed version server-side.
2) keep password in plaintext server-side, but can thus do verification without sending the password in plain (server sends hash of nonce+password, or similar).
#1 is vulnerable to MITM or fake site (DNS poisoning, very similarly named domains, injection attacks), #2 is 100%-game-over if the site is hacked but offers protection against #1 attacks.
With a pubkey scheme, attackers have a much more difficult situation - hacking the server gives them a "not in this lifetime bruteforceable" public key, MITM'ing doesn't work (not for the
proper schemes - again, fsckyou SSL), and to do anything interesting they'd need to trojanize every
individual target.
Got no problems there I've actually been wanting to do a bit of research on the MITM stuff for a while now. I'd like to have a better understanding of the mechanics of exactly what is done and how these attacks work as they are indeed quite troubling.-Stoic Joker
It's pretty scary for SSL. For a "criminal" MITM, you'd normally get a certificate warning, and most somewhat tech-savvy people would at least have a chance of avoiding this.
The
scary part, however, is that governments have always had the capability of getting fake certs signed by a CA, and most people will
not see this, because it looks legitimate. If you use something like Certificate Patrol for firefox, you'll at least see the cert has changed, and will get a warning if it happens long before old cert's expiry time. But other than that, a fake signed cert will look legitimate. And with the break-ins that have been recently at CAs, it's not only governments that have fake certs now.
If I recall, the main obstacle to the widespread use of private/public keys was that it's ok between people who know each other and exchange it, but once you are starting to do it in a more widespread way with people and companies you dont know, how do they get your key, how does it scale? Need a distribution system with some kind of validation to prevent spoofing.-iphigenie
Valid points - it's hard to do right, and you really need a web of trust or similar system... and even that isn't perfect if people just click "yeah yeah, sounds reasonable that this guy has updated his key" without veryfying by phone call or whatever.
There's a difference between requirements for web browsing and for "ensuring the identify of some random person you don't know" - for the web browsing part, I'd kinda prefer NO automatic trust over SSL's model. At least that way, as long as the
first time I visit a server is without any MITM, I'll know if things are afoul from then on. (Unless of course a particular server has been infiltrated, but that'll only give the attackers control of my interaction with
that server).
Recent Posts
, but I had a good idea what was happening when the SSH login times ramped up. When the file copying started stuttering is around the time when DMA errors showed up in 'dmesg' output. I let it run a bit too long before getting a replacement drive, but PANTS-ON-HEAD-RETARDED-luckily lost no data (and apparently no corruption either - some data had .torrent files to check against, others .md5sums). Took around 40 hours to get all data off the drive, though.