
Introducing GitHub Sudo Mode - napolux
https://github.com/blog/1513-introducing-github-sudo-mode
======
Smerity
Whilst 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>

[2]: <http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security>

[3]: <http://www.thoughtcrime.org/software/sslstrip/>

~~~
fintler
I 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.

~~~
calebegg
Lots of sites use RFC 6238 -- Github probably would too. Then you can just use
Google Authenticator (or similar) to manage them.

~~~
mdaniel
I was so disappointed that Twitter's TFA didn't choose to go with the
mechanism you mentioned. Is there a compelling reason not to use it?

~~~
Sealy
Because they wanted to annoy Kim Dotcom.

~~~
mdaniel
I'm sorry, I don't get the joke. Does he break into people's Twitter accounts?

------
B-Con
This 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
You 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
We 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
Ah, 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.

------
spindritf
I'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
1password, and I'm sure keepas and those of its ilk handle them just fine.

~~~
jlogsdon
LastPass handles it fine.

------
simonw
We implemented something similar for our own internal admin accounts recently
on <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
I 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
We 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.

------
hexis
I 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
Amazon'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
The 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
This 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
Not 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.

~~~
peterwwillis
_This is basically malware-safe_

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)

~~~
jsnell
I wasn't talking about phishing, and you must be misunderstanding the protocol
that I described. It's safe from malware that highjacks the browser.

~~~
peterwwillis
How?

~~~
jsnell
I don't understand where you think the attack surface is, and thus can't
address the problem you think exists. So unfortunately the best I can do is
describe the thing again, using different words. Sorry.

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.

~~~
peterwwillis
_The posited malware can't initiate an automatic transaction, since an OTP
from the bank dongle is needed._

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.

------
gingerlime
I really like how gitHub explains this feature in a way most geeks (i.e. its
customer base) would understand instantly. "Ah! just like sudo".

------
peterkelly
Still no option to make me a sandwich :(

------
axyjo
I thought this was around for a while. I guess they just finally got some time
to have a blog post on it.

~~~
mastahyeti
Just shipped it a couple minutes ago. Previously, we only had password
confirmations for adding Public Keys.

~~~
gingerlime
This 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
Adding a new email address is _now_ behind "Sudo Mode"...

~~~
gingerlime
I was talking about the email alerts though, not the password re-check part of
it (or are they basically the same feature?)

------
wtbob
Frankly, 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.

------
pepijndevos
Judging from the title I thought I would be reading about force push from the
web UI.

That'd be a lot of fun.

------
sdfjkl
I 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
How 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
Those 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.

------
mosqutip
This 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?

------
emillon
I 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.

------
SEJeff
I 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

------
brbcoding
The real question though... Is it su-doo mode or su-doh mode?

------
phibit
"Ouh Github made a trivial change, to the front page!"

------
waltz
Sudo Mode ™

