11 ms·
Introducing GitHub Sudo Mode
- axyjo 13y agoI thought this was around for a while. I guess they just finally got some time to have a blog post on it.
- mastahyeti 13y agoJust shipped it a couple minutes ago. Previously, we only had password confirmations for adding Public Keys.
- gingerlime 13y agoThis is nice. Last time I checked, it also emails you when a public key is added, which is a really great feature IMO. 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.
- mastahyeti 13y agoAdding a new email address is now behind "Sudo Mode"...
- gingerlime 13y agoI was talking about the email alerts though, not the password re-check part of it (or are they basically the same feature?)
- RKearney 13y agoAccessing the Applications section also prompted for a password when I tried over the weekend. Either there was more than just the Public Keys that required re-authentication or this was indeed around for longer than just a couple minutes.
- mastahyeti 13y agoThis is a separate issue. We just added the Private Token feature on the /settings/applications page. This is essentially a password, so we wanted to make sure that it required password confirmation. This will be behind sudo mode later today hopefully.
- B-Con 13y agoThis is becoming common practice. A base level of common features are available to a normal login session with particularly sensitive operations requiring re-authentication. 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.
- jcampbell1 13y agoYou are right. I think they should issue a new session id when you escalate. That way someone can't ride your session. 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.
- mastahyeti 13y agoWe use Rails CookieStore. The cookie does change when you enter sudo mode, so a session would have to be compromised while you are in sudo mode.
- jcampbell1 13y agoAh, you are correct. It changes in the tail position, and I was only looking at the first bit. Sorry about that. It seems impossible to ride a session in this case, as the GP suggests.
- CGamesPlay 13y agoA basic security system should automatically revoke any session that repeatedly attempts and fails to get past this secondary authentication. So the attacker would have to know in advance that you had recently freshed your session.
- deleted 13y ago[deleted]
- gingerlime 13y agoI really like how gitHub explains this feature in a way most geeks (i.e. its customer base) would understand instantly. "Ah! just like sudo".
- deleted 13y ago[deleted]
- mosqutip 13y agoThis is cool! I wish more websites would do things like this. 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?
- hexis 13y agoI think Amazon.com has a similar authentication scheme, where lots of stuff is accessible while logged in, but destructive stuff, like making a purchase, requires another log-in. It's a great model, especially when you think of it more like keeping safe things easy rather than making dangerous things hard.
- mmahemoff 13y agoAmazon's been so far ahead of the game on this. 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.
- TillE 13y agoThe really secure version of this is a method used by some banks (eg, all German banks) where your normal login is basically read-only, and any action requires the use of a one-time code. It can be a bit of a hassle, but it makes a lot of sense when dealing with money.
- peterwwillis 13y agoThis requirement of extra security has forced thieves to develop more advanced methods. The easy stuff is malware that intercepts the PIN when you submit it on your desktop, and malware that intercepts SMS PINs can be found in many european mobile apps. The only practical use of 2-factor is to fight password reuse. 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.
- jsnell 13y agoNot true. My bank in Switzerland uses the following scheme: - 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.
- pepijndevos 13y agoJudging from the title I thought I would be reading about force push from the web UI. That'd be a lot of fun.
- spindritf 13y agoI'd love if those additional checks, not only on GitHub but in general, asked you to re-login via the regular login form so that it could be auto-filled by the browser (or other passwords managers) with the same reliability as the the regular login form is. 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.
- kbar13 13y ago1password, and I'm sure keepas and those of its ilk handle them just fine.
- jlogsdon 13y agoLastPass handles it fine.
- munimkazia 13y agoI was thinking about this.. But then, this is supposed to keep us safe if we keep our computers unattended. On the other hand, if you use password managers to autofill passwords, measures like this won't do much to keep you safe if you leave your browser unattended. Bottom line: These measures don't do much, don't leave your computer logged in and unattended at any time.
- simonw 13y agoWe implemented something similar for our own internal admin accounts recently on http://lanyrd.com/ http://lanyrd.com/ 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.
- patio11 13y agoI use something very similar to your system, but people who know better will tell you that your admin functions should be at a distinct app at admin.example.com, which you'd make only accessible to people VPNing into a gateway box which does nothing but VPN. You can secure them normally after that, independently of the service proper. This prevents a variety of attacks, such as leaving as XSS anywhere in your application, from causing you to lose th le admin console.
- simonw 13y agoWe have a seperate set of (more harmful) admin tools that are on an entirely different login system, but yes, going VPN only is definitely a sensible next step.
- emmelaich 13y agoAtlassian also have something similar; "websudo" https://developer.atlassian.com/display/DOCS/Adding+WebSudo+Support+to+your+Plugin https://developer.atlassian.com/display/DOCS/Adding+WebSudo+...
- Smerity 13y agoWhilst yes, GitHub Sudo Mode will certainly help if you leave your machine unattended or someone snipes just your session, but it won't help if someone gets your password. GitHub should have two-factor authentication by now. 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 https://news.ycombinator.com/item?id=5124784 [2]: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [3]: http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/
- fintler 13y agoI already have 4 different fobs on my keychain (not counting my YubiKey for LastPass). I'm not quite sure what I'll do when every website has one and I'll need 20 of them. It also doesn't help that they're all unlabeled. Edit: I just realized I actually have 6 fobs, but I only keep 4 on my keychain.
- peterkelly 13y agoStill no option to make me a sandwich :(
- wtbob 13y agoFrankly, I dislike this kind of thing. My passwords are typically 32-character random strings, stored via a secure mechanism; having to re-enter them means retrieving them from the secure password store and re-entering them. 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.
- phibit 13y ago"Ouh Github made a trivial change, to the front page!"
- waltz 13y agoSudo Mode ™
- sdfjkl 13y agoI find this measure ill conceived. It only protects from unlocked computers and sniffed session cookies. The right way to handle these two problems is to religiously lock your computer when you step away and to serve nothing on port 80 but a permanent redirect to port 443. 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).
- elliotanderson 13y agoHow would serving everything through SSL and "enforcing" workstation locks on people mitigate XSS and CSRF attack vectors? Requiring additional privilege elevation drastically reduces this.
- sdfjkl 13y agoThose are already solved by using CSRF tokens and escaping all the things. Still no reason to bother users with additional password prompts, which come with a number of risks of their own, not least of all causing users to use weaker or shared passwords because they have to enter them all the bloody time.
- charleslmunger 13y agoHTTP Strict Transport Security is a must also.
- SEJeff 13y agoI want to see 2 factor authentication. Not sure about everyone, but I see my github @SEJeff account as more of a resume than LinkedIn ever was. I hate that there aren't more ways to secure it
- emillon 13y agoI think that it introduces a (minor) security risk : if you have access to an idle session, and you can force a user authenticate through another means, then you can exploit the idle session to change password.
- brbcoding 13y agoThe real question though... Is it su-doo mode or su-doh mode?