- [Announcer] The Vendorpedia platform is purpose built
to automate the third party risk lifecycle
with three core capabilities;
assessments and due diligence,
global risk exchange
and vendor chasing services.
- Hello and welcome
to authentication and beyond using Fido
and Push Notification.
If you're joining us live,
our speaker is in a slider discussion now,
answering your questions.
For audio-video issues,
please click the technical support button below.
I'd now like to turn it over
to a Anand Bahety for the presentation.
- Thank you RSA for providing me with this opportunity
to talk about eBay's journey
towards password-less authentication.
Here is the outline for today's talk.
We'll go over current authentication landscape at eBay
and how it has evolved over time.
In spite of having several modes
of authentication already present on the site,
we will discuss why we introduced
yet another authentication framework.
What was the need for it?
We will go to architecture and implementation details
of how we leverage Fido authentication standard,
and Push Notifications technology
to build secure and user friendly authentication framework.
We will go over how this framework helps simplify
Multifactor Authentication Strategy
I will also highlight the challenges we faced
while rolling this framework out
to millions of our customers worldwide
and the best practices we follow.
So without further ado,
let's get started.
Authentication at eBay,
it helps to set the context first
as to what scale we are talking about.
eBay has 134 million customers
and operates over 190 countries.
Given the global presence
and the diverse audience base,
it is very important for us
to provide several authentication mechanisms
to our customers,
so that they can choose what they prefer
and gain secure access to the site.
Here is a snapshot of the sign in screen
and its evolution at eBay.
As you can see from the left to right,
we started from regular username password screen,
and with the ever growing needs
from the customers as well as the industry,
we have introduced a variety
of authentication options on the screen.
Including other identity providers as well.
By implementing
and approaching of identifier first,
where we split the identify screen
and the password,
we are now at a point where
we can provide more relevant
and contextual authentication options
to our customers.
Here's a snapshot
of variety of authentication methods
already present on the site.
As you can see,
it ranges from age old password mechanisms
to several verification methods
like email, SMS, even knowledge based authentication.
We are even introduce login
with other identity providers.
As you can see,
these various mechanisms vary in the spectrum
of security and usability.
In the authentication landscape,
which is ever changing and evolving,
passwords and some other means of authentication
are no longer reliable.
However,
to introduce a new authentication mechanism at eBay,
it's not that trivial given the scale we operate upon.
So what do we look for when we try
to choose an authentication mechanism?
Here are some of the key characteristics
we keep an eye out for.
Security.
First and foremost,
the authentication option has to be secure.
It's the front gate
to accessing all the important services at eBay,
and hence, it's of paramount importance.
Usability.
The option we introduce should be user friendly
and easy to use.
The whole point
of introducing an authentication option
for our customers,
is for them to adopt it,
and then continue using it for as long as they like.
If it's too hard to use,
it's never going to make the cut
and just defeats the purpose.
Maintainability.
The option offered to our customers,
it should be easy for us to maintain as well.
Why?
Being in the business for so long
and carrying a long legacy,
once an option is introduced on eBay,
it's really, really hard to deprecate that.
Even though it might sound easy
that why not deprecate it
but given the business we run,
it's really difficult.
The consumers expect the same options
to be available across all the platforms
so that, they can gain a familiar access
to the site.
We evaluated several options,
but found that either some of them are too complex
or difficult to use.
It's really hard to find out options
which fulfill all the three characteristics
at the same time.
While we were still evaluating several options
to be added to our authentication portfolio,
there comes Fido,
the latest industry standard for authentication.
It's one of its kind,
which is trying to bridge the gap
between security and usability at the same time.
It also helps avoid a lot of attack vectors.
Some of them are as follows;
Shared secrets.
In this protocol
the server does not store any secretive information,
hence it is not susceptible
to server sided data compromises.
Because there is nothing secretive,
which is going over the wire on both sides,
man in the middle attack is rendered useless.
As you can see, this protocol is trying
to cover most of our needs
and became pretty attractive for us.
We implemented it pretty early in the game
to provide biometric based authentication
into the eBay applications on mobile devices.
So that brings a lot of goodness
on to the mobile applications world.
But what about web and other platforms?
How do we bridge the gap there?
We started evaluating options.
Our aim was to maintain the Fido infrastructure
in deployment we had,
as it brings a lot of goodness along with it,
and see what we can use together with that
to bridge the gap
and make the other platforms like web,
equally secure and user friendly.
After evaluating couple of options,
we decided to use Push Notifications
as a delivery mechanism
in conjunction with Fido
to achieve what we were aiming for.
The first question which might come into the mind
is why Push Notifications?
How does it help to secure the web platforms?
Well, we could leverage the widespread adoption
of eBay that's already in the market.
Push Notifications are user friendly,
and they provide seamless access
to either applications.
Usability is a key factor we were on the lookout for
and Push Notifications are just very simple to use.
You do not have to spend time and effort
to educate the users on how to use Push Notifications
in an application.
Alerting.
It might sound trivial to begin with
that hey, Push Notification alerts the user
but in the context of authentication,
it's very important and valuable
to alert the user
before an authentication succeeds against an account.
Compared to other options
where user is alerted pretty late in the game.
Push Notification gives us alerting as a bonus.
Let's see the architecture
and the components of this framework.
First, we have the client site,
the mobile applications,
which gets shipped with the final client libraries.
The other side is the Fido Server
which is hosted on the server
and forms the other part
of the components for this framework.
By the way,
both of these protocols we have open sourced
and I will be providing the links to them
towards the end of the presentation.
Now that we understand the two key components,
let's see how they help in the registration
of this framework.
First, the user is authenticated into the application
with already existing means
of authentication choices.
Then, the client initiates the registration protocol
with the server.
It then enrolls the user
and generates the public and private key pair.
It stores the private key securely on the device
and sends the public key to the server.
At the end of registration,
the eBay server stores only the public key.
This is a very simplified explanation
of the final registration protocol.
Key point to note here is that the private key
is securely stored on the user's device.
Now that the registration is done,
let's see how this aids authentication to users.
Then where a user tries to authenticate on any platform,
we send a Push Notification
to the registered device.
On receiving the notification,
the application initiates the authentication protocol
with the server.
This step also acts as a way for us
to check if the incoming request is valid
and it's not stale.
Then, the application asks the user
to approve the authentication attempt
and uses the private key
securely stored on the device
to sign the notification payload.
To complete the authentication process,
it then sends the signed data back to the server.
The eBay server verifies the signature
by using the public key stored on its premises
against the user account.
If the signature matches,
the authentication attempt is approved
and user logs in securely
and successfully on their account,
on whatever platform they started with.
It is very important to note that
we use the same exact mechanism
to even deny an authentication attempt.
The key point to note here is that
the private key never leaves the user's device.
As you can see,
the secret which is the private key
always stays on the user's device.
There is no chance of any data compromise
on the server side.
It only stores the public key.
And because only signed data
is traveling over the wire,
man in the middle attack is rendered useless.
Now that we understand the registration
and the authentication protocol,
let's look at certain nuances
for the implementation of this framework.
What goes into the notification payload?
Transaction identifier,
it's the only important piece of information
in the notifications payload.
It's short lived, one time use
and by itself no use.
It is only used to transfer the state
of authentication attempt the user started on any platform
and bring it to the registered device
so that we can leverage
the Fido Authentication Protocol
to securely approve or deny.
The transaction identifier by itself causes no harm
because, even though if someone sniffs it
or listens to it,
cannot present it to any of the resources at eBay.
Hence, nothing sensitive is traveling over the wire.
By the virtue of this two properties,
we can avoid a complete end to end TLS establishment
between the client and the server
to secure the notification payload.
We are reusing the existing Fido deployment we had
for the native applications
and complementing it with Push Notifications
to just bring the benefit on all the platforms.
Handling of the Push Notification
was pretty straightforward
inside the existing eBay applications.
We did not have to do any major rewrites,
nor we had to push a separate app
for our users to download.
This just helps in the usability
because customers are already used
to using the eBay application,
we can just leverage that
and provide them a secure platform to sign in.
Let's see how this authentication framework
simplifies Multifactor Authentication Strategies.
It can be used for primary authentication.
Instead of passwords
or other means of mechanisms you have in your application,
we can just use this
as the primary authentication factor.
If you already have established
first factor authentications,
this can be used to provide as a second factor
of authentication option to the users.
It doesn't hurt to provide more options
so that users can add more security to their account.
In fact, this framework can be used
to achieve truly password-less authentication
across all platforms.
The same framework adapts to different steps
in your authentication journey and strategy,
the choice is just yours
where you want to put it to use.
Well, even though everything sounds good so far,
we faced a lot of challenges
while rolling audience of customers worldwide.
If the users have different devices
with different capabilities.
Some have biometric authentication based security,
while some have just plain old pin locks.
We decided to adapt the protocol
so that, it can use
the best available local security on the device.
We did not mandate biometrics,
or a presence of specific OS or hardware
to get the usage of this feature.
Backup factor.
How do we provide an equivalent secure
and easy to use authentication mechanisms
to our customers when they are not in position
to use their primary means
of Push Notification based authentication?
Or they do not have access
to the registered devices?
This is an ongoing challenge
and I think there is no one solution for this.
Key rotation, we're talking about cryptography here.
And the cryptographic guidelines always suggest
to rotate the key pair at periodic intervals of time.
But how do we do that here?
It's not that simple.
In order not to complicate things,
we decided to ask the user
to read a gesture on the framework
in order to indirectly achieve key rotation.
Let's take a look of this framework in action
in terms of how we implemented it.
You are seeing
how the user goes through using this framework
as a second factor authentication means
from left to right.
The user starts attempting the primary factor authentication
and gets a notification
to be approved on the registered device.
Once the user decides whether to approve or not,
they see the feedback immediately
and if they approve it,
the user then gets access to their account securely.
As you can see,
the Push Notification based framework using Fido,
not only allows the user
to get alerted before any damage is done to the account
but also gives them full secure control
whether they can approve
or deny an authentication attempt.
Let's talk about certain use cases
in areas where this framework
can be utilized beyond just authentication.
Account recovery.
The framework helps us verify the user securely, right.
So if we are not using it for primary authentication,
we can very well leverage it
to help users securely recover their account.
Account recovery or backup factors
are basically the weakest link
in the authentication ecosystem.
This framework just helps secure that weakest link.
Trusted Device Management.
Presence of the keys on the device
and its ability to approve
or deny an authentication attempt
establishes implicit trust on the device.
It can leverage that trust
and the protocol we just discussed,
to perform
several trusted device management related actions.
Step-up authentication.
Whenever we have a need to re-authenticate the user
or securely get the user's approval
for any kind of activity which is susceptible to high risk,
we can leverage this authentication framework.
For example, transactions, checkouts, money movements,
personal account related information
related changes, et cetera.
Push Notifications help alert the user
before an activity takes place
and the Fido Authentication Protocol
can then secure through that activity or transaction.
Continuous authentication.
We can leverage this framework to evaluate
and continuously extend
an already authenticated user's session,
so that the user gets frictionless experience
into the application.
We need not ask them to sign in again and again,
at periodic intervals of time.
These are just some of the areas
which actually extend beyond just authentication
where we can leverage
the same framework we just talked about.
So what do you guys think about this framework?
I would love to hear any feedback
or comments on the same,
so please send it along the way on the chat window.
Let's talk about web authentication.
Isn't that the next-gen Fido protocol?
Any talk about Fido authentication
and not talking about web authentication
wouldn't give justice to the protocol.
Yes, we did implement web authentication protocol as well
on selective devices
as a primary authentication means.
The new protocol syntax helps simplify certain complications
of the previous protocol,
but the security paradigm pretty much remains the same.
The private key is securely stored on the user's device
and the public key is stored on the server.
Let's see our implementation approach
towards this protocol.
Given that major user vendors
are now supporting this protocol
as a first class candidate in their release versions,
we decided that we want to offer this
as soon as possible to our customers.
We started evaluating whether we should build it
from the scratch
or just buy off the shelf product
and integrate it.
Even here, we wanted it to coexist
with our existing Fido deployment
for maintainability reasons.
We evaluated several open source servers as well,
and in the end decided to use an open source server,
which just fits in nicely with our deployment,
with some modifications.
We also experimented it with different client platforms,
to understand the nuances of how users adapted
so that we can tweak our flaws
to provide the best possible authentication experience
to our customers.
With all this in mind,
we are still just as an alternative
primary authentication, for now.
Why?
Because we faced a lot of challenges again.
First of all, the protocol does not support
multiple top-level domains.
For an entity like eBay,
which owns multiple sites
having different top-level domains,
the same user with the same account
would have to register
for the web authentication protocol,
again and again on every individual site.
They do not have to do that
with other credentials
and other modes of authentication.
So this is just friction for the user.
Hence, we decided to just implement this
for ebay.com for now.
Back up factor.
This seems to be a standard problem,
which always comes into picture
whenever we introduce a new means of authentication.
The same problem about how do we provide
and secure an equivalent
alternate authentication mechanism to our customers
when they are in not able to use
the primary authentication means
like the about authentication protocol
from the registered devices.
Inconsistent experience.
Different devices like Windows, Mac, Android, et cetera,
provide little different experiences
from the implementation of the protocol.
Now, these nuances matter a lot for us
when we try to cater a user segment
whose age varies from millennials
to grandpas and grandmas.
Lack of common education and awareness
as to what this protocol brings on the table
in terms of goodness and security.
When we provided this option to our users,
some of them were confused as to what is this about.
Even though their devices are fully capable
of supporting the enhanced authentication mechanisms.
We need not reinvent the wheel of educating the users
with every single implementation of the protocol.
I'm really happy to see
that the Fido Alliance
has recently started an initiative
to specifically address this problem.
So let's summarize what we talked about today.
We talked about how Fido
and Push Notifications help provide
a rock solid foundation for secure, easy to use
and robust authentication framework.
We even discussed how we can leverage this framework
to simplify Multifactor Authentication Strategies.
We discuss several areas beyond authentication
where we can leverage the benefit of this framework.
Trusted device management,
step up authentication,
continuous authentication, et cetera.
Are we truly password-less yet?
No.
Because of the challenges I just mentioned,
we are not truly password-less.
All these options are currently
as alternative primary authentication.
Even though we would like to be password-less
and try to reach that goal as soon as we can,
I think it's going to take some time
till we tackle these challenges.
So what's in it for you?
What can you guys do next?
I would suggest that
you evaluate your authentication portfolio.
The options you provide to your customers
to authenticate on your application.
And aim for being truly password-less.
Keep in mind,
I'm not saying that you be password-less from day one
or you have to be password-less.
But if you start thinking from that perspective,
it will help you understand
if you need to introduce alternative means
of authentication like we did
in order for you to be prepared
to reach the end state of being truly password-less.
It never hurts to think early and provide options
to the customers early in the game
rather than scratching in hurry
when there is an absolute need
for a new authentication mechanism.
If you want to experience this firsthand,
you can enable Push Notification based 2FA
on your eBay account
and see how this framework comes to action
and provides you additional security.
If you wanna get your hands on to the core
and play around with some libraries,
we have certain Fido open source libraries on GitHub.
We have certain technical
and product blocks as well.
You can read to gain more insights
into our implementation strategy.
So with that,
thank you very much for listening to this session
and I hope you've got some good insights
into how you can also build a secure, easy to use
and robust authentication framework for your customers.
Thank you RSA once again
and I'll be more than happy
to answer any questions if you have.
Feel free to reach out to me
to discuss this further.
Thank you.