

Why Google Should Customize your Gmail Login Page to Prevent Phishing - EthanHeilman
http://ethanheilman.tumblr.com/post/31897384881/google-should-customize-gmail-login

======
sirclueless
There are several reasons not to do this:

1\. Unless Google can roll this out in a short timeframe to all their
properties with 100% reliability, it's basically useless. If half of their
login screens don't have it, there's no way for a consumer to tell the
difference between a hacked site and a legitimate malfunction (such as a
cleared cache, or fresh computer installation). Luckily, Google's web logins
are already centralized, but people also log into Chrome, their Android
devices, etc.

2\. You can never remove the customization. You better be sure you want to
support custom images forever, because you are committing to a promise: your
customers' login screens will look exactly the same from now on. The only way
to migrate away from it is to bite the bullet and deal with a ton of people
who think that their browser or Google has been hacked because it's missing
their custom picture.

That's too much commitment to a stopgap measure for a password form that
Google wants to obsolete anyways. They'd rather have you authenticate to your
browser or via a device anyways, long term.

~~~
EthanHeilman
1\. Even if they roll it out to all their login pages fresh computers are
still a problem (it is addressed in the article), but the current state of
affairs is that "users can't tell the difference between a hacked site and a
legitimate site". When this system fails it is just as bad as the current
system, when it is setup it is significantly safer.

> You can never remove the customization. 2\. Google can just announce they
> are moving away from the customized login page on their login page. The
> customized login page is trusted so the new information is trusted.

The customization can be framed as an extra security measure that power users
who want to protect themselves from phishing attacks can setup on their home
computer. Similar to the way google rolled out two-factor authentication.

>They'd rather have you authenticate to your browser or via a device anyways,
long term.

Long term this is right login screens will move off of the browser, but
security must be concerned about the now. Note that phishing still presents a
risk on mobile device login screens. As long as your security depends on
something you know, phishing attacks will be relevant, and client-side
identification of trust will still be relevant.

------
k3n
They already have all of this for GAFYD (Google Apps For Your Domain) users,
which has a free version that I've been using for ~5 years:

<https://www.google.com/enterprise/apps/business/pricing.html>

You can set a custom image and apply some simple style tweaks to the sign-in
box on the login page. Here's mine:

<http://i.imgur.com/xReSS.png>

~~~
lemma
FYI - You missed one occurrence of the domain.

~~~
k3n
shhh.. lol

------
DanBlake
The time honored solution to this is not how you propose- Its called double-
stepping and its annoying from a UI perspective.

Step 1: Enter your username and click "go"

Step 2: you are presented with a image you have chosen before- If the image
matches, you enter your password and click continue

USBank.com does this, try it by typing in a random name, like cstevens -
Notice how it doesnt accept a user + pass on the same screen

~~~
ef4
Double stepping is fundamentally weaker from a security perspective. The
phisher can present you the username screen, use it to fetch your correct
image from Google, and present the image to you.

This proposal is better in the sense that the correct image is cached locally
and protected by the browser's local storage origin policy.

------
compsciphd
the easier answer is to leverage SSL authentication. There's no reason we
should have to use passwords every time we login to a site. All sites have to
do is generate a single device asymetric key pair and provide the one part to
the client's browser (we'll call this private) and associate the other part
("public") to whatever account you care about.

Now, you still need some other element to authenticate the user when they
visit a website from a new device/browser, but this would mean that you don't
have long term cookies that serve the same role and are therefore more
extractable over the wire (as we've seen in the past) and would negate these
type of attacks.

Also, the tech exists in browsers today already, many SSL registrars already
do it.

------
hamoid
"3. This is really the tricky part as an attacker can wipe browser cookies at
will."

No need for an attacker, I do wipe them at will. Every time I close the
browser.

------
adrianb
It's what Yahoo has been doing for a while. They call it "Sign-in seal" and
it's basically a custom picture you select yourself.

------
purplelobster
There have been studies showing that users don't notice the absence of cues
like this.

~~~
ninjin
Oooh, I'd love to have a link to that. Is this recent work?

------
1SaltwaterC
Why? Their two factor authentication works just fine.

~~~
EthanHeilman
Someone can just steal your two factor authentication token by asking for one
at a forged login page.

~~~
1SaltwaterC
It's not that easy. I use the "push" authentication model, aka Google sends me
an SMS whenever I need to authenticate a _device_. I don't request it
explicitly. The pairing is made between the authentication code, and that
device. Now, if it happens that I'm stupid enough to enter my login details
into a fake page, the interesting part would be the lack of SMS from the
Google side, but I will get an SMS when somebody else would try the
credentials. Tough break. Besides, this week's phishing attempt asked me my:
name, Google account, password, recovery email address. They say that https is
as secure as the user that's using it. Same goes for this stuff.

device = browser profile, aka for two browsers on the same machine you need
two authentication tokens. Same goes for the same browser with two profiles.

------
drivebyacct2
What about machines with multiple Gmail users? Counting on user data when the
user is logged out seems like a major problem right off the bat. (But how is a
hacker going to clear your cookies remotely?)

