Introducing GitHub Sudo Mode
github.com
github.com
We've already seen the Github SSL replaced by a self-signed certificate in China[1] and I'm sure other similar situations have occurred, so stealing the password via man-in-the-middle or a similar attack is feasible. GitHub uses HSTS[2] but something like SSLStrip[3] only needs to work once for your account and repositories to be compromised.
GitHub, like it or not, is the key to a lot of valuable resources. From private repositories for start-ups or large companies to public open source repositories used by millions, they're all potentially vulnerable.
I should clarify that I do love GitHub, they've improved collaboration in the open source scene substantially, but when something like homakov's GitHub exploit occurs, you realise how important GitHub's security is.
[1]: https://news.ycombinator.com/item?id=5124784
[2]: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Edit: I just realized I actually have 6 fobs, but I only keep 4 on my keychain.
The trend of everything moving towards smartphones limits my options. However, YubiKey OTP works well, so it's not a big issue -- I just hope more competition pops up.
Also, personally I trust fobs more than my smartphone. My smartphone is a device which is always connected to a network. I don't want to be one remote exploit and a password leak away from having every credential I control compromised.
It seems that this really only defends against idle session hijacking, though. If the attacker is in a position to ride on whatever session they want, they'll just wait for an "elevated" session.
The classic sudo-esque escalation model can be configured to only allow sudo sessions within terminals, so doing one sudo doesn't suddenly allow the entire system "sudo" access. If it did, a malicious program could just sit and hit the priviledged operation with "sudo" until they got let in. The web's "sudo" is essentially this, because all authentication sessions go over HTTP and you can't really sandbox the source as nicely.
[edit] (HN had a funny hiccup there. Anyway...)
It would be interesting if we could get the same thing on the web. Perhaps some new type of cookie is considered "temporary, ultra-safe" by the browser and never written to disk, auto-cleared after X time, only transfered over HTTPS, etc.
I checked, and it appears they don't regenerate the session id when escalating.
I am not an expert, but I think this is a case where you want to regenerate the session id.
It seems impossible to ride a session in this case, as the GP suggests.
Now, it requires you to fish out and paste the password from the manager into this, yet another, special field.
EDIT: I know that some managers can guess when to use the password in a different context on the same site. But not all of them and not all the time.
Mozilla's manager (built into Firefox) doesn't do it properly on Google accounts page, or on GitHub. At least it didn't yesterday.
Bottom line: These measures don't do much, don't leave your computer logged in and unattended at any time.
We have a bunch of admin tools that are only available to our team members, for all kinds of minor administrative tasks. These show up with a nasty pink background to remind us that they are admin-only, which gets in the way of doing demos and taking screenshots.
We also support federated login via Twitter and LinkedIn, and were unhappy with the idea that someone might break the security on one of those services and use that to hijack a privileged admin account on our own site (sure, they likely have better account security than us in general, but they are a much more tempting target for attackers).
So... we added the concept of an "admin upgrade" - a link site admins can click to enter an account password and temporarily elevate their privileges. This improves the security of our admin accounts and has the pleasant side-effect of making it much easier for us to take screenshots and give demos without exposing our admin functions.
This prevents a variety of attacks, such as leaving as XSS anywhere in your application, from causing you to lose th le admin console.
https://developer.atlassian.com/display/DOCS/Adding+WebSudo+...
I'd like to see more authentication frameworks take this use case into account. "Logged-in" should actually be a spectrum of at least 3 states, not binary.
It can be a bit of a hassle, but it makes a lot of sense when dealing with money.
So really, they should just ask for a PIN once instead of for every action. But I bet it makes people feel more safe to keep entering it.
- For logging in, I enter a 6 digit code to the dongle. It spits out a 8 letter pass-phrase, which I then enter to the website.
- For authorizing payments, I need to enter the last 5 digits from the account number to the dongle. Again it produces a passphrase.
- The authorization is only required the first time you make a payment to an account. So it's not even particularly annoying.
This is basically malware-safe, assuming a user who understands how the scheme works. The result from a 6-digit input code is useless to an attacker, and no amount of malware on the computer can make me enter a 5-digit code (since I'd read those numbers from the paper invoice). Likewise highjacking form submission and changing the account number when I enter a payment would do the attacker no good.
The malware only needs to monitor your session until you enter whatever credentials were prompted of you by the real-live site, upon which it captures the connection, prevents your post, and does an automatic drive-by withdrawl from your account.
Phishing is a different discussion. For users who don't know better (which is 99% of them) they will just ask you for whatever they want, with a carbon copy of the content of the real site, and once provided with it, will do whatever one-time transaction you would have done on the real site. The only difference is they don't need malware to do this.
Combine the two (perhaps with some slight-of-hand using your own browser's UI) and they can challenge and authorize a payment to an account you don't realize is incorrect. If you double-checked the account number you might realize the switch.
For most American banks none of what you described is offered to the consumer or business owner. In Europe there's just an extra step in the way for the fraud. (Swiss bank accounts would, I assume, require more stringent security procedures than most other banks)
The posited malware can't initiate an automatic transaction, since an OTP from the bank dongle is needed. The dongle needs to be seeded with a specific part of the receiver's account number, so just any OTP generated by the dongle won't do. The account number has been passed out of band (generally on a paper invoice), so taking control of my browser doesn't give the attacker a way of fooling me into generating an OTP suitable for use with their account either.
This attack hinges on intercepting a human entering in authentication information by hand into what they think is a secure, valid site. The human will be doing manual stuff, but the code is automated.
The account number has been passed out of band
If it was not passed out of band, or a phishing or mitm attack changes the account number and the user doesn't notice, this attack will work. It's a difficult but rewarding targeted attack similar to those used by the chinese, eastern europeans, etc.
And there should be better messaging for that.
For the last year or so I've been amused and then frustrated by ebay having a "Welcome, username" message in the header, but requiring another login before I can do anything relating to my account. Just providing a login link in the header would cut in half how many clicks I have to go through to add something to my watch list.
However, it doesn't (didn't?) email you when you change your email address. So if you want to silently add a public key, you can temporarily change the email address, add the key, and then change the email back. Of course it's not a huge concern, since you need the password anyway, but it just makes relying on this email alert slightly less reliable.
Apologies if this has been changed/fixed already. I haven't tested it recently.
My computer is under my physical control at all times while I'm authenticated; I don't need a website to ask me to reprove it over and over.
That'd be a lot of fun.
As spindritf pointed out, it merely serves to annoy (or worse, forces passwords to be transported via system clipboards which tends to increase the security risk).
Side note: would it be possible to add user customization to this? As in, make this the default level, but have an option for requiring the password on all "dangerous actions" regardless of the elapsed time?