1
00:00:11,040 --> 00:00:13,410
- [Announcer] The Vendorpedia
platform is purpose built

2
00:00:13,410 --> 00:00:15,930
to automate the third party risk lifecycle

3
00:00:15,930 --> 00:00:17,980
with three core capabilities;

4
00:00:17,980 --> 00:00:19,940
assessments and due diligence,

5
00:00:19,940 --> 00:00:21,600
global risk exchange

6
00:00:21,600 --> 00:00:23,583
and vendor chasing services.

7
00:00:28,760 --> 00:00:30,160
- Hello and welcome

8
00:00:30,160 --> 00:00:32,980
to authentication and beyond using Fido

9
00:00:32,980 --> 00:00:34,930
and Push Notification.

10
00:00:34,930 --> 00:00:35,890
If you're joining us live,

11
00:00:35,890 --> 00:00:38,083
our speaker is in a slider discussion now,

12
00:00:39,130 --> 00:00:40,600
answering your questions.

13
00:00:40,600 --> 00:00:42,070
For audio-video issues,

14
00:00:42,070 --> 00:00:45,120
please click the technical
support button below.

15
00:00:45,120 --> 00:00:45,952
I'd now like to turn it over

16
00:00:45,953 --> 00:00:48,673
to a Anand Bahety for the presentation.

17
00:00:53,590 --> 00:00:56,950
- Thank you RSA for providing
me with this opportunity

18
00:00:56,950 --> 00:00:58,550
to talk about eBay's journey

19
00:00:58,550 --> 00:01:00,623
towards password-less authentication.

20
00:01:01,529 --> 00:01:04,110
Here is the outline for today's talk.

21
00:01:04,110 --> 00:01:08,050
We'll go over current
authentication landscape at eBay

22
00:01:08,050 --> 00:01:10,003
and how it has evolved over time.

23
00:01:10,870 --> 00:01:12,760
In spite of having several modes

24
00:01:12,760 --> 00:01:15,230
of authentication already
present on the site,

25
00:01:15,230 --> 00:01:17,280
we will discuss why we introduced

26
00:01:17,280 --> 00:01:20,040
yet another authentication framework.

27
00:01:20,040 --> 00:01:21,543
What was the need for it?

28
00:01:22,740 --> 00:01:25,619
We will go to architecture
and implementation details

29
00:01:25,620 --> 00:01:28,990
of how we leverage Fido
authentication standard,

30
00:01:28,990 --> 00:01:31,350
and Push Notifications technology

31
00:01:31,350 --> 00:01:36,315
to build secure and user friendly
authentication framework.

32
00:01:36,315 --> 00:01:39,920
We will go over how this
framework helps simplify

33
00:01:39,920 --> 00:01:42,480
Multifactor Authentication Strategy

34
00:01:42,480 --> 00:01:45,040
I will also highlight
the challenges we faced

35
00:01:45,040 --> 00:01:47,070
while rolling this framework out

36
00:01:47,070 --> 00:01:49,520
to millions of our customers worldwide

37
00:01:49,520 --> 00:01:52,140
and the best practices we follow.

38
00:01:52,140 --> 00:01:53,800
So without further ado,

39
00:01:53,800 --> 00:01:55,163
let's get started.

40
00:01:56,320 --> 00:01:58,100
Authentication at eBay,

41
00:01:58,100 --> 00:02:00,419
it helps to set the context first

42
00:02:00,420 --> 00:02:02,593
as to what scale we are talking about.

43
00:02:03,540 --> 00:02:06,250
eBay has 134 million customers

44
00:02:06,250 --> 00:02:08,810
and operates over 190 countries.

45
00:02:08,810 --> 00:02:10,759
Given the global presence

46
00:02:10,759 --> 00:02:13,350
and the diverse audience base,

47
00:02:13,350 --> 00:02:14,960
it is very important for us

48
00:02:14,960 --> 00:02:17,790
to provide several
authentication mechanisms

49
00:02:17,790 --> 00:02:19,070
to our customers,

50
00:02:19,070 --> 00:02:21,850
so that they can choose what they prefer

51
00:02:21,850 --> 00:02:24,132
and gain secure access to the site.

52
00:02:25,430 --> 00:02:28,510
Here is a snapshot of the sign in screen

53
00:02:28,510 --> 00:02:30,380
and its evolution at eBay.

54
00:02:30,380 --> 00:02:32,940
As you can see from the left to right,

55
00:02:32,940 --> 00:02:36,260
we started from regular
username password screen,

56
00:02:36,260 --> 00:02:38,019
and with the ever growing needs

57
00:02:38,020 --> 00:02:40,660
from the customers as
well as the industry,

58
00:02:40,660 --> 00:02:42,480
we have introduced a variety

59
00:02:42,480 --> 00:02:45,660
of authentication options on the screen.

60
00:02:45,660 --> 00:02:49,510
Including other identity
providers as well.

61
00:02:49,510 --> 00:02:50,750
By implementing

62
00:02:50,750 --> 00:02:53,940
and approaching of identifier first,

63
00:02:53,940 --> 00:02:56,150
where we split the identify screen

64
00:02:56,150 --> 00:02:57,560
and the password,

65
00:02:57,560 --> 00:02:59,100
we are now at a point where

66
00:02:59,100 --> 00:03:01,370
we can provide more relevant

67
00:03:01,370 --> 00:03:03,860
and contextual authentication options

68
00:03:03,860 --> 00:03:04,863
to our customers.

69
00:03:06,020 --> 00:03:07,090
Here's a snapshot

70
00:03:07,090 --> 00:03:09,540
of variety of authentication methods

71
00:03:09,540 --> 00:03:11,750
already present on the site.

72
00:03:11,750 --> 00:03:12,583
As you can see,

73
00:03:12,583 --> 00:03:15,600
it ranges from age old password mechanisms

74
00:03:15,600 --> 00:03:17,710
to several verification methods

75
00:03:17,710 --> 00:03:22,160
like email, SMS, even
knowledge based authentication.

76
00:03:22,160 --> 00:03:24,270
We are even introduce login

77
00:03:24,270 --> 00:03:26,770
with other identity providers.

78
00:03:26,770 --> 00:03:27,750
As you can see,

79
00:03:27,750 --> 00:03:30,620
these various mechanisms
vary in the spectrum

80
00:03:30,620 --> 00:03:32,463
of security and usability.

81
00:03:33,300 --> 00:03:34,960
In the authentication landscape,

82
00:03:34,960 --> 00:03:37,640
which is ever changing and evolving,

83
00:03:37,640 --> 00:03:40,410
passwords and some other
means of authentication

84
00:03:40,410 --> 00:03:42,053
are no longer reliable.

85
00:03:43,370 --> 00:03:44,320
However,

86
00:03:44,320 --> 00:03:47,250
to introduce a new
authentication mechanism at eBay,

87
00:03:47,250 --> 00:03:51,710
it's not that trivial given
the scale we operate upon.

88
00:03:51,710 --> 00:03:53,930
So what do we look for when we try

89
00:03:53,930 --> 00:03:56,420
to choose an authentication mechanism?

90
00:03:56,420 --> 00:03:58,980
Here are some of the key characteristics

91
00:03:58,980 --> 00:04:00,393
we keep an eye out for.

92
00:04:01,660 --> 00:04:02,493
Security.

93
00:04:02,493 --> 00:04:03,609
First and foremost,

94
00:04:03,610 --> 00:04:06,300
the authentication
option has to be secure.

95
00:04:06,300 --> 00:04:07,530
It's the front gate

96
00:04:07,530 --> 00:04:10,420
to accessing all the
important services at eBay,

97
00:04:10,420 --> 00:04:13,040
and hence, it's of paramount importance.

98
00:04:14,377 --> 00:04:15,890
Usability.

99
00:04:15,890 --> 00:04:18,680
The option we introduce
should be user friendly

100
00:04:18,680 --> 00:04:20,269
and easy to use.

101
00:04:20,269 --> 00:04:21,169
The whole point

102
00:04:21,170 --> 00:04:23,630
of introducing an authentication option

103
00:04:23,630 --> 00:04:24,690
for our customers,

104
00:04:24,690 --> 00:04:26,410
is for them to adopt it,

105
00:04:26,410 --> 00:04:29,740
and then continue using it
for as long as they like.

106
00:04:29,740 --> 00:04:31,530
If it's too hard to use,

107
00:04:31,530 --> 00:04:33,479
it's never going to make the cut

108
00:04:33,480 --> 00:04:35,862
and just defeats the purpose.

109
00:04:35,862 --> 00:04:37,400
Maintainability.

110
00:04:37,400 --> 00:04:40,380
The option offered to our customers,

111
00:04:40,380 --> 00:04:43,170
it should be easy for
us to maintain as well.

112
00:04:43,170 --> 00:04:44,160
Why?

113
00:04:44,160 --> 00:04:45,810
Being in the business for so long

114
00:04:45,810 --> 00:04:48,020
and carrying a long legacy,

115
00:04:48,020 --> 00:04:50,159
once an option is introduced on eBay,

116
00:04:50,160 --> 00:04:53,050
it's really, really
hard to deprecate that.

117
00:04:53,050 --> 00:04:56,330
Even though it might sound easy

118
00:04:56,330 --> 00:04:57,919
that why not deprecate it

119
00:04:57,920 --> 00:04:59,900
but given the business we run,

120
00:04:59,900 --> 00:05:01,429
it's really difficult.

121
00:05:01,430 --> 00:05:03,660
The consumers expect the same options

122
00:05:03,660 --> 00:05:06,440
to be available across all the platforms

123
00:05:06,440 --> 00:05:10,040
so that, they can gain a familiar access

124
00:05:10,040 --> 00:05:10,873
to the site.

125
00:05:12,440 --> 00:05:14,730
We evaluated several options,

126
00:05:14,730 --> 00:05:17,840
but found that either some
of them are too complex

127
00:05:17,840 --> 00:05:19,849
or difficult to use.

128
00:05:19,850 --> 00:05:22,330
It's really hard to find out options

129
00:05:22,330 --> 00:05:25,130
which fulfill all the
three characteristics

130
00:05:25,130 --> 00:05:26,263
at the same time.

131
00:05:27,195 --> 00:05:30,780
While we were still
evaluating several options

132
00:05:30,780 --> 00:05:34,229
to be added to our
authentication portfolio,

133
00:05:34,230 --> 00:05:35,730
there comes Fido,

134
00:05:35,730 --> 00:05:39,100
the latest industry
standard for authentication.

135
00:05:39,100 --> 00:05:40,520
It's one of its kind,

136
00:05:40,520 --> 00:05:42,419
which is trying to bridge the gap

137
00:05:42,420 --> 00:05:46,300
between security and
usability at the same time.

138
00:05:46,300 --> 00:05:49,700
It also helps avoid a
lot of attack vectors.

139
00:05:49,700 --> 00:05:51,522
Some of them are as follows;

140
00:05:52,470 --> 00:05:53,780
Shared secrets.

141
00:05:53,780 --> 00:05:54,809
In this protocol

142
00:05:54,810 --> 00:05:57,840
the server does not store
any secretive information,

143
00:05:57,840 --> 00:05:59,989
hence it is not susceptible

144
00:05:59,990 --> 00:06:02,253
to server sided data compromises.

145
00:06:03,200 --> 00:06:05,349
Because there is nothing secretive,

146
00:06:05,350 --> 00:06:08,360
which is going over
the wire on both sides,

147
00:06:08,360 --> 00:06:11,520
man in the middle attack
is rendered useless.

148
00:06:11,520 --> 00:06:14,109
As you can see, this protocol is trying

149
00:06:14,110 --> 00:06:16,010
to cover most of our needs

150
00:06:16,010 --> 00:06:18,070
and became pretty attractive for us.

151
00:06:18,070 --> 00:06:21,360
We implemented it pretty early in the game

152
00:06:21,360 --> 00:06:23,980
to provide biometric based authentication

153
00:06:23,980 --> 00:06:27,410
into the eBay applications
on mobile devices.

154
00:06:27,410 --> 00:06:29,200
So that brings a lot of goodness

155
00:06:29,200 --> 00:06:32,300
on to the mobile applications world.

156
00:06:32,300 --> 00:06:35,383
But what about web and other platforms?

157
00:06:36,390 --> 00:06:38,969
How do we bridge the gap there?

158
00:06:38,970 --> 00:06:41,520
We started evaluating options.

159
00:06:41,520 --> 00:06:44,580
Our aim was to maintain
the Fido infrastructure

160
00:06:44,580 --> 00:06:45,950
in deployment we had,

161
00:06:45,950 --> 00:06:49,060
as it brings a lot of
goodness along with it,

162
00:06:49,060 --> 00:06:51,900
and see what we can use together with that

163
00:06:51,900 --> 00:06:53,010
to bridge the gap

164
00:06:53,010 --> 00:06:55,219
and make the other platforms like web,

165
00:06:55,220 --> 00:06:57,273
equally secure and user friendly.

166
00:06:58,250 --> 00:07:00,140
After evaluating couple of options,

167
00:07:00,140 --> 00:07:03,140
we decided to use Push Notifications

168
00:07:03,140 --> 00:07:04,870
as a delivery mechanism

169
00:07:04,870 --> 00:07:06,270
in conjunction with Fido

170
00:07:06,270 --> 00:07:08,503
to achieve what we were aiming for.

171
00:07:09,500 --> 00:07:11,440
The first question which
might come into the mind

172
00:07:11,440 --> 00:07:13,550
is why Push Notifications?

173
00:07:13,550 --> 00:07:18,050
How does it help to
secure the web platforms?

174
00:07:18,050 --> 00:07:21,650
Well, we could leverage
the widespread adoption

175
00:07:21,650 --> 00:07:23,972
of eBay that's already in the market.

176
00:07:24,860 --> 00:07:27,820
Push Notifications are user friendly,

177
00:07:27,820 --> 00:07:29,830
and they provide seamless access

178
00:07:29,830 --> 00:07:31,620
to either applications.

179
00:07:31,620 --> 00:07:34,830
Usability is a key factor
we were on the lookout for

180
00:07:34,830 --> 00:07:38,159
and Push Notifications are
just very simple to use.

181
00:07:38,160 --> 00:07:40,741
You do not have to spend time and effort

182
00:07:40,741 --> 00:07:43,969
to educate the users on how
to use Push Notifications

183
00:07:43,970 --> 00:07:45,083
in an application.

184
00:07:46,160 --> 00:07:47,160
Alerting.

185
00:07:47,160 --> 00:07:48,800
It might sound trivial to begin with

186
00:07:48,800 --> 00:07:51,250
that hey, Push Notification
alerts the user

187
00:07:51,250 --> 00:07:54,460
but in the context of authentication,

188
00:07:54,460 --> 00:07:57,250
it's very important and valuable

189
00:07:57,250 --> 00:07:58,470
to alert the user

190
00:07:58,470 --> 00:08:01,813
before an authentication
succeeds against an account.

191
00:08:03,540 --> 00:08:04,693
Compared to other options

192
00:08:04,693 --> 00:08:08,390
where user is alerted
pretty late in the game.

193
00:08:08,390 --> 00:08:11,683
Push Notification gives
us alerting as a bonus.

194
00:08:13,440 --> 00:08:14,350
Let's see the architecture

195
00:08:14,350 --> 00:08:17,390
and the components of this framework.

196
00:08:17,390 --> 00:08:19,000
First, we have the client site,

197
00:08:19,000 --> 00:08:20,320
the mobile applications,

198
00:08:20,320 --> 00:08:22,993
which gets shipped with
the final client libraries.

199
00:08:24,420 --> 00:08:26,170
The other side is the Fido Server

200
00:08:26,170 --> 00:08:27,480
which is hosted on the server

201
00:08:27,480 --> 00:08:28,627
and forms the other part

202
00:08:28,627 --> 00:08:31,310
of the components for this framework.

203
00:08:31,310 --> 00:08:32,220
By the way,

204
00:08:32,220 --> 00:08:34,510
both of these protocols
we have open sourced

205
00:08:34,510 --> 00:08:36,640
and I will be providing the links to them

206
00:08:36,640 --> 00:08:39,250
towards the end of the presentation.

207
00:08:39,250 --> 00:08:41,860
Now that we understand
the two key components,

208
00:08:41,860 --> 00:08:44,510
let's see how they help
in the registration

209
00:08:44,510 --> 00:08:46,939
of this framework.

210
00:08:46,940 --> 00:08:49,880
First, the user is authenticated
into the application

211
00:08:49,880 --> 00:08:51,370
with already existing means

212
00:08:51,370 --> 00:08:53,670
of authentication choices.

213
00:08:53,670 --> 00:08:57,050
Then, the client initiates
the registration protocol

214
00:08:57,050 --> 00:08:58,370
with the server.

215
00:08:58,370 --> 00:09:00,570
It then enrolls the user

216
00:09:00,570 --> 00:09:03,730
and generates the public
and private key pair.

217
00:09:03,730 --> 00:09:06,910
It stores the private key
securely on the device

218
00:09:06,910 --> 00:09:09,719
and sends the public key to the server.

219
00:09:09,720 --> 00:09:11,670
At the end of registration,

220
00:09:11,670 --> 00:09:15,120
the eBay server stores
only the public key.

221
00:09:15,120 --> 00:09:17,710
This is a very simplified explanation

222
00:09:17,710 --> 00:09:19,653
of the final registration protocol.

223
00:09:21,070 --> 00:09:23,610
Key point to note here
is that the private key

224
00:09:23,610 --> 00:09:26,533
is securely stored on the user's device.

225
00:09:27,730 --> 00:09:29,800
Now that the registration is done,

226
00:09:29,800 --> 00:09:34,609
let's see how this aids
authentication to users.

227
00:09:34,610 --> 00:09:38,620
Then where a user tries to
authenticate on any platform,

228
00:09:38,620 --> 00:09:40,600
we send a Push Notification

229
00:09:40,600 --> 00:09:42,720
to the registered device.

230
00:09:42,720 --> 00:09:44,850
On receiving the notification,

231
00:09:44,850 --> 00:09:47,736
the application initiates
the authentication protocol

232
00:09:47,736 --> 00:09:49,150
with the server.

233
00:09:49,150 --> 00:09:51,660
This step also acts as a way for us

234
00:09:51,660 --> 00:09:54,890
to check if the incoming request is valid

235
00:09:54,890 --> 00:09:56,063
and it's not stale.

236
00:09:57,000 --> 00:09:59,520
Then, the application asks the user

237
00:09:59,520 --> 00:10:02,090
to approve the authentication attempt

238
00:10:02,090 --> 00:10:03,620
and uses the private key

239
00:10:03,620 --> 00:10:05,890
securely stored on the device

240
00:10:05,890 --> 00:10:08,830
to sign the notification payload.

241
00:10:08,830 --> 00:10:11,170
To complete the authentication process,

242
00:10:11,170 --> 00:10:16,170
it then sends the signed
data back to the server.

243
00:10:16,380 --> 00:10:19,680
The eBay server verifies the signature

244
00:10:19,680 --> 00:10:22,530
by using the public key
stored on its premises

245
00:10:22,530 --> 00:10:24,260
against the user account.

246
00:10:24,260 --> 00:10:25,880
If the signature matches,

247
00:10:25,880 --> 00:10:28,090
the authentication attempt is approved

248
00:10:28,090 --> 00:10:29,970
and user logs in securely

249
00:10:29,970 --> 00:10:32,060
and successfully on their account,

250
00:10:32,060 --> 00:10:34,183
on whatever platform they started with.

251
00:10:35,070 --> 00:10:36,900
It is very important to note that

252
00:10:36,900 --> 00:10:39,490
we use the same exact mechanism

253
00:10:39,490 --> 00:10:42,470
to even deny an authentication attempt.

254
00:10:42,470 --> 00:10:44,620
The key point to note here is that

255
00:10:44,620 --> 00:10:48,440
the private key never
leaves the user's device.

256
00:10:48,440 --> 00:10:49,273
As you can see,

257
00:10:49,273 --> 00:10:50,847
the secret which is the private key

258
00:10:50,847 --> 00:10:53,569
always stays on the user's device.

259
00:10:53,570 --> 00:10:56,240
There is no chance of any data compromise

260
00:10:56,240 --> 00:10:57,150
on the server side.

261
00:10:57,150 --> 00:10:59,040
It only stores the public key.

262
00:10:59,040 --> 00:11:01,130
And because only signed data

263
00:11:01,130 --> 00:11:02,730
is traveling over the wire,

264
00:11:02,730 --> 00:11:05,473
man in the middle attack
is rendered useless.

265
00:11:06,720 --> 00:11:08,550
Now that we understand the registration

266
00:11:08,550 --> 00:11:10,719
and the authentication protocol,

267
00:11:10,720 --> 00:11:12,300
let's look at certain nuances

268
00:11:12,300 --> 00:11:14,349
for the implementation of this framework.

269
00:11:15,330 --> 00:11:18,380
What goes into the notification payload?

270
00:11:18,380 --> 00:11:19,860
Transaction identifier,

271
00:11:19,860 --> 00:11:22,180
it's the only important
piece of information

272
00:11:22,180 --> 00:11:24,290
in the notifications payload.

273
00:11:24,290 --> 00:11:26,250
It's short lived, one time use

274
00:11:26,250 --> 00:11:28,163
and by itself no use.

275
00:11:29,230 --> 00:11:31,720
It is only used to transfer the state

276
00:11:31,720 --> 00:11:36,220
of authentication attempt the
user started on any platform

277
00:11:36,220 --> 00:11:38,670
and bring it to the registered device

278
00:11:38,670 --> 00:11:40,150
so that we can leverage

279
00:11:40,150 --> 00:11:42,260
the Fido Authentication Protocol

280
00:11:42,260 --> 00:11:44,423
to securely approve or deny.

281
00:11:45,930 --> 00:11:49,410
The transaction identifier
by itself causes no harm

282
00:11:49,410 --> 00:11:53,060
because, even though if someone sniffs it

283
00:11:53,060 --> 00:11:54,500
or listens to it,

284
00:11:54,500 --> 00:11:57,960
cannot present it to any
of the resources at eBay.

285
00:11:57,960 --> 00:12:01,530
Hence, nothing sensitive
is traveling over the wire.

286
00:12:01,530 --> 00:12:04,220
By the virtue of this two properties,

287
00:12:04,220 --> 00:12:07,960
we can avoid a complete end
to end TLS establishment

288
00:12:07,960 --> 00:12:09,575
between the client and the server

289
00:12:09,575 --> 00:12:11,413
to secure the notification payload.

290
00:12:13,409 --> 00:12:16,630
We are reusing the existing
Fido deployment we had

291
00:12:16,630 --> 00:12:18,780
for the native applications

292
00:12:18,780 --> 00:12:21,689
and complementing it
with Push Notifications

293
00:12:21,690 --> 00:12:24,323
to just bring the benefit
on all the platforms.

294
00:12:26,510 --> 00:12:28,100
Handling of the Push Notification

295
00:12:28,100 --> 00:12:29,470
was pretty straightforward

296
00:12:29,470 --> 00:12:32,030
inside the existing eBay applications.

297
00:12:32,030 --> 00:12:34,880
We did not have to do any major rewrites,

298
00:12:34,880 --> 00:12:37,490
nor we had to push a separate app

299
00:12:37,490 --> 00:12:40,490
for our users to download.

300
00:12:40,490 --> 00:12:42,200
This just helps in the usability

301
00:12:42,200 --> 00:12:44,390
because customers are already used

302
00:12:44,390 --> 00:12:45,990
to using the eBay application,

303
00:12:45,990 --> 00:12:47,460
we can just leverage that

304
00:12:47,460 --> 00:12:50,153
and provide them a secure
platform to sign in.

305
00:12:51,970 --> 00:12:54,260
Let's see how this
authentication framework

306
00:12:54,260 --> 00:12:58,330
simplifies Multifactor
Authentication Strategies.

307
00:12:58,330 --> 00:13:00,803
It can be used for primary authentication.

308
00:13:01,810 --> 00:13:03,050
Instead of passwords

309
00:13:03,050 --> 00:13:05,729
or other means of mechanisms
you have in your application,

310
00:13:05,730 --> 00:13:07,180
we can just use this

311
00:13:07,180 --> 00:13:09,910
as the primary authentication factor.

312
00:13:09,910 --> 00:13:12,420
If you already have established

313
00:13:12,420 --> 00:13:14,380
first factor authentications,

314
00:13:14,380 --> 00:13:16,930
this can be used to
provide as a second factor

315
00:13:16,930 --> 00:13:19,479
of authentication option to the users.

316
00:13:19,480 --> 00:13:21,730
It doesn't hurt to provide more options

317
00:13:21,730 --> 00:13:25,260
so that users can add more
security to their account.

318
00:13:25,260 --> 00:13:28,020
In fact, this framework can be used

319
00:13:28,020 --> 00:13:30,850
to achieve truly
password-less authentication

320
00:13:30,850 --> 00:13:33,490
across all platforms.

321
00:13:33,490 --> 00:13:37,030
The same framework
adapts to different steps

322
00:13:37,030 --> 00:13:39,709
in your authentication
journey and strategy,

323
00:13:39,710 --> 00:13:41,100
the choice is just yours

324
00:13:41,100 --> 00:13:43,053
where you want to put it to use.

325
00:13:45,330 --> 00:13:49,000
Well, even though everything
sounds good so far,

326
00:13:49,000 --> 00:13:51,010
we faced a lot of challenges

327
00:13:51,010 --> 00:13:53,623
while rolling audience
of customers worldwide.

328
00:13:55,320 --> 00:13:57,244
If the users have different devices

329
00:13:57,244 --> 00:13:59,070
with different capabilities.

330
00:13:59,070 --> 00:14:02,060
Some have biometric
authentication based security,

331
00:14:02,060 --> 00:14:05,099
while some have just plain old pin locks.

332
00:14:05,100 --> 00:14:07,340
We decided to adapt the protocol

333
00:14:07,340 --> 00:14:09,190
so that, it can use

334
00:14:09,190 --> 00:14:12,490
the best available local
security on the device.

335
00:14:12,490 --> 00:14:14,890
We did not mandate biometrics,

336
00:14:14,890 --> 00:14:17,800
or a presence of specific OS or hardware

337
00:14:17,800 --> 00:14:19,892
to get the usage of this feature.

338
00:14:21,500 --> 00:14:23,180
Backup factor.

339
00:14:23,180 --> 00:14:25,400
How do we provide an equivalent secure

340
00:14:25,400 --> 00:14:28,380
and easy to use authentication mechanisms

341
00:14:28,380 --> 00:14:32,870
to our customers when
they are not in position

342
00:14:32,870 --> 00:14:34,470
to use their primary means

343
00:14:34,470 --> 00:14:37,700
of Push Notification based authentication?

344
00:14:37,700 --> 00:14:39,000
Or they do not have access

345
00:14:39,000 --> 00:14:41,360
to the registered devices?

346
00:14:41,360 --> 00:14:44,310
This is an ongoing challenge

347
00:14:44,310 --> 00:14:47,223
and I think there is no
one solution for this.

348
00:14:48,780 --> 00:14:52,083
Key rotation, we're talking
about cryptography here.

349
00:14:52,083 --> 00:14:55,209
And the cryptographic
guidelines always suggest

350
00:14:55,210 --> 00:14:58,630
to rotate the key pair at
periodic intervals of time.

351
00:14:58,630 --> 00:15:00,510
But how do we do that here?

352
00:15:00,510 --> 00:15:02,660
It's not that simple.

353
00:15:02,660 --> 00:15:04,829
In order not to complicate things,

354
00:15:04,830 --> 00:15:06,780
we decided to ask the user

355
00:15:06,780 --> 00:15:09,530
to read a gesture on the framework

356
00:15:10,370 --> 00:15:13,063
in order to indirectly
achieve key rotation.

357
00:15:15,460 --> 00:15:18,280
Let's take a look of
this framework in action

358
00:15:18,280 --> 00:15:21,030
in terms of how we implemented it.

359
00:15:21,030 --> 00:15:22,209
You are seeing

360
00:15:22,210 --> 00:15:24,570
how the user goes through
using this framework

361
00:15:24,570 --> 00:15:26,670
as a second factor authentication means

362
00:15:26,670 --> 00:15:28,569
from left to right.

363
00:15:28,570 --> 00:15:32,040
The user starts attempting the
primary factor authentication

364
00:15:32,040 --> 00:15:33,730
and gets a notification

365
00:15:33,730 --> 00:15:36,330
to be approved on the registered device.

366
00:15:36,330 --> 00:15:39,500
Once the user decides
whether to approve or not,

367
00:15:39,500 --> 00:15:41,700
they see the feedback immediately

368
00:15:41,700 --> 00:15:42,890
and if they approve it,

369
00:15:42,890 --> 00:15:46,270
the user then gets access
to their account securely.

370
00:15:46,270 --> 00:15:47,760
As you can see,

371
00:15:47,760 --> 00:15:50,930
the Push Notification
based framework using Fido,

372
00:15:50,930 --> 00:15:52,609
not only allows the user

373
00:15:52,610 --> 00:15:55,220
to get alerted before any
damage is done to the account

374
00:15:55,220 --> 00:15:58,920
but also gives them full secure control

375
00:15:58,920 --> 00:15:59,939
whether they can approve

376
00:15:59,940 --> 00:16:01,863
or deny an authentication attempt.

377
00:16:03,810 --> 00:16:06,099
Let's talk about certain use cases

378
00:16:06,100 --> 00:16:07,840
in areas where this framework

379
00:16:07,840 --> 00:16:10,763
can be utilized beyond
just authentication.

380
00:16:11,860 --> 00:16:13,490
Account recovery.

381
00:16:13,490 --> 00:16:17,520
The framework helps us verify
the user securely, right.

382
00:16:17,520 --> 00:16:20,300
So if we are not using it
for primary authentication,

383
00:16:20,300 --> 00:16:22,030
we can very well leverage it

384
00:16:22,030 --> 00:16:25,360
to help users securely
recover their account.

385
00:16:25,360 --> 00:16:27,990
Account recovery or backup factors

386
00:16:27,990 --> 00:16:29,480
are basically the weakest link

387
00:16:29,480 --> 00:16:31,950
in the authentication ecosystem.

388
00:16:31,950 --> 00:16:36,103
This framework just helps
secure that weakest link.

389
00:16:37,040 --> 00:16:38,900
Trusted Device Management.

390
00:16:38,900 --> 00:16:40,740
Presence of the keys on the device

391
00:16:40,740 --> 00:16:42,950
and its ability to approve

392
00:16:42,950 --> 00:16:44,880
or deny an authentication attempt

393
00:16:44,880 --> 00:16:47,890
establishes implicit trust on the device.

394
00:16:47,890 --> 00:16:49,840
It can leverage that trust

395
00:16:49,840 --> 00:16:52,340
and the protocol we just discussed,

396
00:16:52,340 --> 00:16:53,250
to perform

397
00:16:53,250 --> 00:16:56,623
several trusted device
management related actions.

398
00:16:57,790 --> 00:16:59,870
Step-up authentication.

399
00:16:59,870 --> 00:17:03,090
Whenever we have a need to
re-authenticate the user

400
00:17:03,090 --> 00:17:06,280
or securely get the user's approval

401
00:17:06,280 --> 00:17:09,762
for any kind of activity which
is susceptible to high risk,

402
00:17:10,660 --> 00:17:13,163
we can leverage this
authentication framework.

403
00:17:14,150 --> 00:17:17,770
For example, transactions,
checkouts, money movements,

404
00:17:17,770 --> 00:17:19,470
personal account related information

405
00:17:19,470 --> 00:17:21,930
related changes, et cetera.

406
00:17:21,930 --> 00:17:24,839
Push Notifications help alert the user

407
00:17:24,839 --> 00:17:27,119
before an activity takes place

408
00:17:27,119 --> 00:17:29,979
and the Fido Authentication Protocol

409
00:17:29,980 --> 00:17:33,713
can then secure through that
activity or transaction.

410
00:17:35,430 --> 00:17:36,620
Continuous authentication.

411
00:17:36,620 --> 00:17:39,800
We can leverage this framework to evaluate

412
00:17:39,800 --> 00:17:41,190
and continuously extend

413
00:17:41,190 --> 00:17:44,180
an already authenticated user's session,

414
00:17:44,180 --> 00:17:47,100
so that the user gets
frictionless experience

415
00:17:47,100 --> 00:17:48,610
into the application.

416
00:17:48,610 --> 00:17:51,780
We need not ask them to
sign in again and again,

417
00:17:51,780 --> 00:17:53,483
at periodic intervals of time.

418
00:17:54,560 --> 00:17:56,300
These are just some of the areas

419
00:17:56,300 --> 00:17:59,500
which actually extend
beyond just authentication

420
00:17:59,500 --> 00:18:00,670
where we can leverage

421
00:18:00,670 --> 00:18:03,930
the same framework we just talked about.

422
00:18:03,930 --> 00:18:06,500
So what do you guys think
about this framework?

423
00:18:06,500 --> 00:18:08,220
I would love to hear any feedback

424
00:18:08,220 --> 00:18:09,530
or comments on the same,

425
00:18:09,530 --> 00:18:12,543
so please send it along
the way on the chat window.

426
00:18:15,320 --> 00:18:17,253
Let's talk about web authentication.

427
00:18:18,270 --> 00:18:20,670
Isn't that the next-gen Fido protocol?

428
00:18:20,670 --> 00:18:23,150
Any talk about Fido authentication

429
00:18:23,150 --> 00:18:25,340
and not talking about web authentication

430
00:18:25,340 --> 00:18:27,959
wouldn't give justice to the protocol.

431
00:18:27,960 --> 00:18:31,880
Yes, we did implement web
authentication protocol as well

432
00:18:31,880 --> 00:18:33,870
on selective devices

433
00:18:33,870 --> 00:18:35,912
as a primary authentication means.

434
00:18:37,520 --> 00:18:41,710
The new protocol syntax helps
simplify certain complications

435
00:18:41,710 --> 00:18:43,160
of the previous protocol,

436
00:18:43,160 --> 00:18:46,770
but the security paradigm
pretty much remains the same.

437
00:18:46,770 --> 00:18:49,970
The private key is securely
stored on the user's device

438
00:18:49,970 --> 00:18:53,233
and the public key is
stored on the server.

439
00:18:55,530 --> 00:18:57,620
Let's see our implementation approach

440
00:18:57,620 --> 00:18:59,530
towards this protocol.

441
00:18:59,530 --> 00:19:01,750
Given that major user vendors

442
00:19:01,750 --> 00:19:04,710
are now supporting this protocol

443
00:19:04,710 --> 00:19:07,450
as a first class candidate
in their release versions,

444
00:19:07,450 --> 00:19:09,600
we decided that we want to offer this

445
00:19:09,600 --> 00:19:11,453
as soon as possible to our customers.

446
00:19:12,630 --> 00:19:14,750
We started evaluating
whether we should build it

447
00:19:14,750 --> 00:19:15,790
from the scratch

448
00:19:15,790 --> 00:19:17,550
or just buy off the shelf product

449
00:19:17,550 --> 00:19:18,543
and integrate it.

450
00:19:20,230 --> 00:19:22,540
Even here, we wanted it to coexist

451
00:19:22,540 --> 00:19:24,620
with our existing Fido deployment

452
00:19:24,620 --> 00:19:27,149
for maintainability reasons.

453
00:19:27,150 --> 00:19:29,870
We evaluated several open
source servers as well,

454
00:19:29,870 --> 00:19:33,070
and in the end decided to
use an open source server,

455
00:19:33,070 --> 00:19:35,659
which just fits in nicely
with our deployment,

456
00:19:35,660 --> 00:19:37,313
with some modifications.

457
00:19:38,150 --> 00:19:42,210
We also experimented it with
different client platforms,

458
00:19:42,210 --> 00:19:45,050
to understand the nuances
of how users adapted

459
00:19:45,050 --> 00:19:47,600
so that we can tweak our flaws

460
00:19:47,600 --> 00:19:50,280
to provide the best possible
authentication experience

461
00:19:50,280 --> 00:19:51,493
to our customers.

462
00:19:52,520 --> 00:19:54,300
With all this in mind,

463
00:19:54,300 --> 00:19:56,540
we are still just as an alternative

464
00:19:56,540 --> 00:19:59,940
primary authentication, for now.

465
00:19:59,940 --> 00:20:00,773
Why?

466
00:20:00,773 --> 00:20:02,822
Because we faced a lot
of challenges again.

467
00:20:04,720 --> 00:20:06,545
First of all, the
protocol does not support

468
00:20:06,545 --> 00:20:08,290
multiple top-level domains.

469
00:20:09,300 --> 00:20:10,899
For an entity like eBay,

470
00:20:10,900 --> 00:20:12,440
which owns multiple sites

471
00:20:12,440 --> 00:20:14,600
having different top-level domains,

472
00:20:14,600 --> 00:20:16,469
the same user with the same account

473
00:20:16,470 --> 00:20:17,370
would have to register

474
00:20:17,370 --> 00:20:19,555
for the web authentication protocol,

475
00:20:19,556 --> 00:20:23,780
again and again on every individual site.

476
00:20:23,780 --> 00:20:24,649
They do not have to do that

477
00:20:24,650 --> 00:20:26,930
with other credentials

478
00:20:26,930 --> 00:20:28,820
and other modes of authentication.

479
00:20:28,820 --> 00:20:31,340
So this is just friction for the user.

480
00:20:31,340 --> 00:20:34,189
Hence, we decided to just implement this

481
00:20:34,190 --> 00:20:36,013
for ebay.com for now.

482
00:20:37,500 --> 00:20:38,850
Back up factor.

483
00:20:38,850 --> 00:20:41,100
This seems to be a standard problem,

484
00:20:41,100 --> 00:20:42,487
which always comes into picture

485
00:20:42,488 --> 00:20:45,760
whenever we introduce a new
means of authentication.

486
00:20:45,760 --> 00:20:48,550
The same problem about how do we provide

487
00:20:48,550 --> 00:20:50,080
and secure an equivalent

488
00:20:51,657 --> 00:20:55,060
alternate authentication
mechanism to our customers

489
00:20:55,060 --> 00:20:58,540
when they are in not able to use

490
00:20:58,540 --> 00:21:00,310
the primary authentication means

491
00:21:00,310 --> 00:21:01,990
like the about authentication protocol

492
00:21:01,990 --> 00:21:03,833
from the registered devices.

493
00:21:05,600 --> 00:21:07,050
Inconsistent experience.

494
00:21:07,050 --> 00:21:11,409
Different devices like Windows,
Mac, Android, et cetera,

495
00:21:11,410 --> 00:21:14,270
provide little different experiences

496
00:21:14,270 --> 00:21:16,570
from the implementation of the protocol.

497
00:21:16,570 --> 00:21:19,629
Now, these nuances matter a lot for us

498
00:21:19,630 --> 00:21:22,220
when we try to cater a user segment

499
00:21:22,220 --> 00:21:25,590
whose age varies from millennials

500
00:21:25,590 --> 00:21:27,233
to grandpas and grandmas.

501
00:21:29,030 --> 00:21:32,139
Lack of common education and awareness

502
00:21:32,140 --> 00:21:35,420
as to what this protocol
brings on the table

503
00:21:35,420 --> 00:21:37,770
in terms of goodness and security.

504
00:21:37,770 --> 00:21:40,660
When we provided this option to our users,

505
00:21:40,660 --> 00:21:43,650
some of them were confused
as to what is this about.

506
00:21:43,650 --> 00:21:46,210
Even though their
devices are fully capable

507
00:21:46,210 --> 00:21:50,043
of supporting the enhanced
authentication mechanisms.

508
00:21:50,878 --> 00:21:54,939
We need not reinvent the
wheel of educating the users

509
00:21:54,940 --> 00:21:57,433
with every single
implementation of the protocol.

510
00:21:58,500 --> 00:22:00,110
I'm really happy to see

511
00:22:00,110 --> 00:22:01,520
that the Fido Alliance

512
00:22:01,520 --> 00:22:04,070
has recently started an initiative

513
00:22:04,070 --> 00:22:07,003
to specifically address this problem.

514
00:22:09,100 --> 00:22:12,520
So let's summarize what
we talked about today.

515
00:22:12,520 --> 00:22:14,080
We talked about how Fido

516
00:22:14,080 --> 00:22:16,840
and Push Notifications help provide

517
00:22:16,840 --> 00:22:20,480
a rock solid foundation
for secure, easy to use

518
00:22:20,480 --> 00:22:22,783
and robust authentication framework.

519
00:22:23,710 --> 00:22:26,660
We even discussed how we
can leverage this framework

520
00:22:26,660 --> 00:22:30,133
to simplify Multifactor
Authentication Strategies.

521
00:22:31,960 --> 00:22:34,860
We discuss several areas
beyond authentication

522
00:22:34,860 --> 00:22:38,469
where we can leverage the
benefit of this framework.

523
00:22:38,470 --> 00:22:39,880
Trusted device management,

524
00:22:39,880 --> 00:22:41,448
step up authentication,

525
00:22:41,448 --> 00:22:43,923
continuous authentication, et cetera.

526
00:22:46,060 --> 00:22:48,669
Are we truly password-less yet?

527
00:22:48,670 --> 00:22:49,730
No.

528
00:22:49,730 --> 00:22:52,606
Because of the challenges
I just mentioned,

529
00:22:52,606 --> 00:22:54,580
we are not truly password-less.

530
00:22:54,580 --> 00:22:56,550
All these options are currently

531
00:22:56,550 --> 00:22:59,470
as alternative primary authentication.

532
00:22:59,470 --> 00:23:02,010
Even though we would
like to be password-less

533
00:23:02,010 --> 00:23:06,280
and try to reach that
goal as soon as we can,

534
00:23:06,280 --> 00:23:07,793
I think it's going to take some time

535
00:23:07,793 --> 00:23:09,882
till we tackle these challenges.

536
00:23:12,100 --> 00:23:13,240
So what's in it for you?

537
00:23:13,240 --> 00:23:15,453
What can you guys do next?

538
00:23:16,700 --> 00:23:17,810
I would suggest that

539
00:23:17,810 --> 00:23:20,250
you evaluate your
authentication portfolio.

540
00:23:20,250 --> 00:23:22,640
The options you provide to your customers

541
00:23:22,640 --> 00:23:24,720
to authenticate on your application.

542
00:23:24,720 --> 00:23:27,313
And aim for being truly password-less.

543
00:23:28,240 --> 00:23:29,073
Keep in mind,

544
00:23:29,073 --> 00:23:32,140
I'm not saying that you be
password-less from day one

545
00:23:32,140 --> 00:23:34,280
or you have to be password-less.

546
00:23:34,280 --> 00:23:37,320
But if you start thinking
from that perspective,

547
00:23:37,320 --> 00:23:38,679
it will help you understand

548
00:23:38,680 --> 00:23:41,150
if you need to introduce alternative means

549
00:23:41,150 --> 00:23:43,490
of authentication like we did

550
00:23:43,490 --> 00:23:45,900
in order for you to be prepared

551
00:23:45,900 --> 00:23:48,820
to reach the end state of
being truly password-less.

552
00:23:48,820 --> 00:23:52,760
It never hurts to think
early and provide options

553
00:23:52,760 --> 00:23:55,220
to the customers early in the game

554
00:23:55,220 --> 00:23:57,060
rather than scratching in hurry

555
00:23:57,060 --> 00:23:58,970
when there is an absolute need

556
00:23:58,970 --> 00:24:01,553
for a new authentication mechanism.

557
00:24:02,700 --> 00:24:05,610
If you want to experience this firsthand,

558
00:24:05,610 --> 00:24:08,669
you can enable Push Notification based 2FA

559
00:24:08,670 --> 00:24:09,770
on your eBay account

560
00:24:09,770 --> 00:24:11,790
and see how this framework comes to action

561
00:24:11,790 --> 00:24:13,639
and provides you additional security.

562
00:24:15,500 --> 00:24:17,370
If you wanna get your hands on to the core

563
00:24:17,370 --> 00:24:18,989
and play around with some libraries,

564
00:24:18,990 --> 00:24:21,993
we have certain Fido open
source libraries on GitHub.

565
00:24:23,610 --> 00:24:26,010
We have certain technical

566
00:24:26,010 --> 00:24:27,840
and product blocks as well.

567
00:24:27,840 --> 00:24:29,929
You can read to gain more insights

568
00:24:29,930 --> 00:24:32,193
into our implementation strategy.

569
00:24:33,240 --> 00:24:35,087
So with that,

570
00:24:35,087 --> 00:24:38,050
thank you very much for
listening to this session

571
00:24:38,050 --> 00:24:40,680
and I hope you've got some good insights

572
00:24:40,680 --> 00:24:43,850
into how you can also
build a secure, easy to use

573
00:24:43,850 --> 00:24:47,760
and robust authentication
framework for your customers.

574
00:24:47,760 --> 00:24:49,470
Thank you RSA once again

575
00:24:49,470 --> 00:24:50,990
and I'll be more than happy

576
00:24:50,990 --> 00:24:53,140
to answer any questions if you have.

577
00:24:53,140 --> 00:24:54,680
Feel free to reach out to me

578
00:24:54,680 --> 00:24:56,310
to discuss this further.

579
00:24:56,310 --> 00:24:57,143
Thank you.