Is my use case inappropriate?

[Tyler]

I'm creating an application that will be used by many people with
unique accounts on a single machine with essentially no gap between
their uses (think of a university machine and application that is
shared by many students). As such, there really needs to be a way to
require users to enter their password each time. Even a short
credential lifespan which might work okay for public computers in
other scenarios won't be sufficient for this. So I'm wondering if
there are plans to enable sites to optionally require users to re-
enter their passwords every time.

I love the ease of use of this API (for both the user and the
developer), but I'm starting to think it's really not intended for
shared machine use.

[Dan Callahan]

Hi Tyler,

On 6/4/12 1:38 PM, Tyler wrote:
> I'm creating an application that will be used by many people with
> unique accounts on a single machine with essentially no gap between
> their uses (think of a university machine and application that is
> shared by many students). As such, there really needs to be a way to
> require users to enter their password each time. Even a short
> credential lifespan which might work okay for public computers in
> other scenarios won't be sufficient for this. So I'm wondering if
> there are plans to enable sites to optionally require users to re-
> enter their passwords every time.

We don't have any plans for being able to force users to re-enter their
passwords, nor could we. At its core, the BrowserID protocol simply
allows users to prove that they've successfully authenticated with their
identity provider; we don't control and can't influence that
authentication in any way.

(Some identity providers might not even use passwords at all!)

What exactly are you trying to achieve by making sure the users re-enter
their passwords each time? Are you trying to be extra-certain that they
are who they say they are, or are you trying to protect User 1 from User
2, who might sit down at the machine next? Perhaps something else entirely?

> I love the ease of use of this API (for both the user and the
> developer), but I'm starting to think it's really not intended for
> shared machine use.

We want Persona to be awesome for general shared machine use, though
your specific use case might fall on the edges of where we're focusing.

I'd love it if you could tell me more about the specific ways in which
you machine and application are going to be used, and how we're possibly
/ currently not meeting your needs.

Thanks for posting and looking at our solution!

Keep the feedback coming,
-Callahad

[Mike G]

I like the option for required password each time. Twitter has this option.
Seems like extra secure apps would benefit.

> ______________________________**_________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>

[Dan Callahan]

Hey Mike,

On 6/4/12 5:42 PM, Mike G wrote:
> I like the option for required password each time.

Can you tell me more about why you like this option?

What does "each time" mean to you? Each time the user clicks "sign in"
on your site?

What do you gain by having this assurance?

> Twitter has this option.

Could you point me to their docs for this? My google-fu is failing me :)

> Seems like extra secure apps would benefit.

How would they benefit? All you're getting is "Yeah, this user really
can log in to eyedee.me as Foo." But that's exactly what a valid
assertion already tells you, isn't it?

It seems like high security apps would be better off adding an
additional auth factor -- like a one-time-password system or a
user-specific PIN code -- after getting a valid BrowserID assertion.

-Callahad

[Mike G]

Each time is every time an assertation is requested. Bear in mind, Im not
using the javascript type where the javascript is used on each page.

https://dev.twitter.com/docs/api/1/get/oauth/authenticate
see force login

For me, there are 2 security considerations. A computer left open would let
someone else automatically log in. Second, it would make sure you are
logging into the correct account.

My historical use with twitter was making sure people used the correct
account, usually, personal vs business account.

This security would allow banks to use browserid, or bitcoin exchanges,
extreme security. But then again, you already have the javascript logout
call which twitter does not have, which we could use to stop auto logins.

Thanks,
Mike

[di_o...@yahoo.com]

Thanks, Dan,

You essentially named the concern - protecting User 1 from User 2 who will definitely be sitting down at the machine directly after User 1 finishes. The software I'm creating will often be used at home, but it will also be used by classes at schools. Teachers will have students go to the machine in succession to use the software, and each student must log into the application with his/her own account. I can reasonably expect users to sign out of my application after they are finished with a session, but I can't (nor would I want) to ensure that they log out from the identity provider. In essence, a solution that would seem to fit me well would be for individual client sites to have the option to request that password verification be demanded again by the provider before returning a positive, even if the user is already logged in with that provider.

The password requirement could certainly be done on my end - I was just hoping to retain the advantages in security and convenience that come with avoiding that.

[Ben Adida]

On 6/4/12 3:28 PM, Dan Callahan wrote:
> We don't have any plans for being able to force users to re-enter their
> passwords, nor could we. At its core, the BrowserID protocol simply
> allows users to prove that they've successfully authenticated with their
> identity provider; we don't control and can't influence that
> authentication in any way.

Dan makes a very good point as to why this is hard, but actually it's
not impossible nor meaningless, and I can imagine some use cases that
warrant some level of "re-authentication."

Technically speaking, there are two main approaches we could take:

- allow the RP to request an assertion backed by certificate obtained no
earlier than X minutes ago. This would ensure that the user was recently
logged into their IdP. This could be pretty simple, and doesn't even
require IdP cooperation: we can simply kill the cert and ask for a new
one. But it's not very flexible other than "make sure user is recently
auth'ed". It certainly doesn't address use cases that are concerned with
an attacker at the user's keyboard being forced to re-authenticate.

- allow the RP to request a different "level of assurance" for the cert,
e.g. "for payments", which would require having that level of assurance
indicated in the certificate itself, and could, with the IdP's
cooperation, require additional authentication. For example, an IdP
could ask for a purchasing PIN, to be retyped for a new cert, valid only
for a couple of minutes. There could also be a generic "high-security"
level of assurance, which would require re-auth for every new cert and
issue certs with very short validity periods.

This second option is much more powerful, fulfills many more use cases,
but requires IdP cooperation. I lean towards this second option with
levels-of-assurance support.

But before we dig too deep, we have to go back to use cases as the
driving force.

Tyler: the use case you describe seems, as Dan mentioned, somewhere in
the middle between shared and public machine use. Are you sure this is
what you need?

Specifically, do you envision that students will click "yes, this is my
machine" on these shared machines they use?

-Ben

[Burak Yiğit Kaya]

I always liked the idea of "assurance level" and I really liked the
application that Ben suggested for this case. I think it is the way to go.

Burak Yiğit "BYK" Kaya <http://byk.im>

On Tue, Jun 5, 2012 at 5:20 AM, Ben Adida <b...@adida.net> wrote:

>
>
> On 6/4/12 3:28 PM, Dan Callahan wrote:
>

>> We don't have any plans for being able to force users to re-enter their
>> passwords, nor could we. At its core, the BrowserID protocol simply
>> allows users to prove that they've successfully authenticated with their
>> identity provider; we don't control and can't influence that
>> authentication in any way.
>>
>

[di.o...@gmail.com]

Hi Ben,

Thanks for the detailed feedback. For my particular situation, I would think that either of the solutions you proposed would work. Your second option could certainly fulfill more use cases that go beyond the requirements I need to fulfill.

To answer your question, yes, I think some students will identify school computers as personal computers when asked, thereby bypassing this protection. I believe many students won't be as concerned about security as will be the teachers and parents who will hold me responsible once students realize they can view each others' grades or personal info with this trick. This problem is currently compounded by how the user is asked multiple times whether the machine is public or personal, but even if the question was only asked once in the beginning, I couldn't guarantee that the teacher would be the one to make the decision. In short, if this choice is left up to the user, I probably need to look for a different solution to protect myself. User error is expected, and I'm expected to know and protect against that to a reasonable degree.

Currently, even when choosing the public computer option, the expiration of the certificate takes too long, allowing different students to log in right after each other. But even if this time limit was variable, I'd still be left with trusting the user to identify the machine as Public, and I can't assume that.

Thanks,
Tyler

[Mike Connor]

On 2012-06-05, at 11:38 AM, di.o...@gmail.com wrote:

> On Monday, June 4, 2012 9:20:12 PM UTC-5, Ben Adida wrote:
>> Specifically, do you envision that students will click "yes, this is my
>> machine" on these shared machines they use?
>>

> To answer your question, yes, I think some students will identify school computers as personal computers when asked, thereby bypassing this protection. I believe many students won't be as concerned about security as will be the teachers and parents who will hold me responsible once students realize they can view each others' grades or personal info with this trick. This problem is currently compounded by how the user is asked multiple times whether the machine is public or personal, but even if the question was only asked once in the beginning, I couldn't guarantee that the teacher would be the one to make the decision. In short, if this choice is left up to the user, I probably need to look for a different solution to protect myself. User error is expected, and I'm expected to know and protect against that to a reasonable degree.

So… a question, and I assume someone here would know if this has already been proposed somewhere, but why can't we try to address this on the user agent level? In the common case of public shared machines (libraries, schools, etc) there could be a pref (likely hidden) set by admins to indicate that the browser is a shared device (or, conversely, not a shared device ever), and expose this somewhere on the navigator object and/or headers. Any login system that wants to make different choices depending on that context would then be able to act based on the user's intent without needing to ask. The user agent could also do intelligent things like only storing cookies for the current session, and similar choices for local storage, etc.

(Yes, I recognize that every user-configurable option exposed to sites can be used as a part of fingerprinting. I don't think that's a major issue in this specific case, since fingerprinting these machines feels like it'd be irrelevant.)

[di.o...@gmail.com]

On Monday, June 4, 2012 9:20:12 PM UTC-5, Ben Adida wrote:

Hi Ben,

Thanks for the detailed feedback. For my particular situation, I would think that either of the solutions you proposed would work. Your second option could certainly fulfill more use cases that go beyond the requirements I need to fulfill.

To answer your question, yes, I think some students will identify school computers as personal computers when asked, thereby bypassing this protection. I believe many students won't be as concerned about security as will be the teachers and parents who will hold me responsible once students realize they can view each others' grades or personal info with this trick. This problem is currently compounded by how the user is asked multiple times whether the machine is public or personal, but even if the question was only asked once in the beginning, I couldn't guarantee that the teacher would be the one to make the decision. In short, if this choice is left up to the user, I probably need to look for a different solution to protect myself. User error is expected, and I'm expected to know and protect against that to a reasonable degree.

[Ben Adida]

On 6/5/12 12:06 PM, Mike Connor wrote:
> So… a question, and I assume someone here would know if this has
> already been proposed somewhere, but why can't we try to address this
> on the user agent level?

We can certainly make the feature better by involving the user agent,
but I don't think we can fully rely on new user-agent features to get
the solution at least mostly right, since we don't control all user
agents, and people need a cross-user-agent solution.

So, yes, I think you've got a good point re: the possibility that a user
agent in "guest mode" with native identity built in could automatically
set the cert length to something fairly low (and our IdP protocol
already takes that possibility into account). But I don't think we can
fully punt on the problem with that future approach.

-Ben

[Dan Callahan]

On 6/5/12 10:38 AM, di.o...@gmail.com wrote:
> Currently, even when choosing the public computer option, the expiration of the certificate takes too long

I'm not entirely certain that having shorter duration certificates would
completely do the trick. Sure, the browser's cert may expire, but in the
process of authenticating, the users also established a session with
their Identity Provider (Gmail, Hotmail, etc.) that we can't timeout.

So the browser would be able to silently get a new cert, wouldn't it?

-Callahad

[Ben Adida]

Yes, that's why I don't love this solution.

That said, playing devil's advocate to myself for a second... if the
user stays logged into their IdP on a shared machine... isn't that a
problem far beyond our scope?

-Ben