Slashdot Mirror
New Authentication Scheme Proposed
jerel brings us a story about a prototype authentication system which approaches security from an atypical angle. It focuses on hiding identity challenges from attackers in addition to the responses. The system, Undercover [PDF], "uses a combination of visual and tactile signals in the authentication process."
"The system displays a set of images to the user and asks if any belongs to the image portfolio that the user had previously selected. At the same time, the trackball sends the user a signal that maps each button on the case to a certain answer. The user's hand must cover the trackball for it to operate, so a sneaky observer wouldn't be able to see his or her selections, or answers. So a would-be attacker can't 'see' the tactile challenge presented by the trackball and therefore doesn't get the user's authentication data, even though he or she could see the image challenge on the display."
And within a month, someone will figure out a way to crack it. It's inevitable.
For all those hackers lined up behind me, looking into my monitor!
For some obscure reason, i accidentally posted this in the wrong thread... please mod parent down (off topic) thank you :/
ps. Also, i left out the "profit" step
Blah blah sig blah blah blah irony blah blah
That's ok, you didn't get first post anyways.
:-) )
(I did the same thing once btw, don't feel bad
.. is some kind of RSA Keyfob-esq authentication at the ATM. Someone sees my pin.. no biggie.. it's invalid as soon as I use it!
...I suggest a booth with a dance dance revolution mat inside.
When the user is asked to enter their password they enter the booth, shut the door and strut their funky password.
Why oh why develop new fancy ways to authenticate that still rely on a one factor (the image portfolio) when 3 factor authentication (eg. username + password + one time pad with challenge and response codes) just works, as snooping the username and pw doesn't give you the one time pad with challenges and responses, and stealing the pad doesn't give you the username and pw.
That is the principal method of authentication used by web banks atleast in Finland and other sensible countries :)
I've seen keypads with digital readout on the keys used in jails (my job takes me in and out of jails frequently). The keypad scrambles the digits each time and there is a prism-type covering over the keys so that unless you are looking directly at it you cannot see the numbers on each key. In order to see the numbers you need to stand in such a way that no one else can see them (your head blocks their view from the only angle the numbers are readable from).
I tried to get the code by watching as the guards let me in and out, just to see how effective it was, and can say that I never succeeded in even getting close. What was even better is that from talking to the offenders I learned that they thought they knew the codes by watching the patterns the keys were pressed by the guards -- I didn't have the heart to tell them that using the pattern they had watched would actually punch in a different code than the one the guards used. I did make sure one of the guards knew about it though.
Sigs are for losers.
They seem to have big plans for this yet have only tested it with 38 users?
Visit ssjx.co.uk
What stops someone from installing a 'keylogger' (albeit for a track ball)? Its a cute idea, but slight of hand only goes so far.
this is my sig, there are many like it, but this one is mine.
"The system displays a set of images to the user and asks if any belongs to the image portfolio that the user had previously selected"
Heh, finally a use for all that porn I've amassed.
Hm, combined with tactile feedback too? This could be very interesting.
Aww crap... sorry... I thought TFA was about Encryption, not Authentication... so instead of a potential +5 Funny, I get a -1 Irrelevant.
That's what I get for posting at 5:30am before I've had my caffeine.
Karma: Excellent. 15 moderator points expire sometime.
It is a cool idea, that is for sure, but it would never leave the lab. Why? Because these guys are obviously not usability engineers. The idea that the function of a button changes based on some random event, and the system will tell you which button means what before you click it, is not usable.
I would like to see a formal usability study done on this thing I don't think it would get very far. I see they had some informal study going on where they had participation and error rates, but no data on what kind of users.
Seems to me that having the ATM download a set of images every time someone logs in is gonna suck bandwidth wise.
How about having a rotating keypad on the computer screen? So when typing your pin, you must map the number on your numberpad to the one on the screen? So the actual input is different from your pin all the way.
The problem with this type of system is that in order to protect the data you are asking the user to go through much more of a rigmarole than entering a password. Here in lies the problem, users will hate this, I mean good security practice is a balance of securing against likely threats and practicality.
I can't see what this does that a fingerprint scanner doesn't. I could be wrong but I can't think of a way to use a keylogger to capture it and it certainly stops someone looking over your shoulder.
A thistle is a fat salad for an ass's mouth...
My bank has been doing this for about a half a year now. It's just a slight spin off from CAPTCHA or whatever the hell the acronym is.
"If you plant ice, you're gonna harvest wind."
Okay, I guess that is slightly more useful than what I've used my Mindstorm kit for.
If at first you don't succeed, call it version 1.0.
Someone I know has developed a similar system that uses a standard, fixed position keypad: The screen (ATM, mobile phone, point-of-sale etc) displays a grid and superimposes jumbled up and repeated numbers over the spaces. Using your secret _pattern_ that is known to the authentication service, you type in the corresponding numbers. Even if someone sees the numbers you type, it is difficult to determine your secret pattern because of duplicate positions for the same number. It's called GrIDsure.
Would I be able to still fit my password on that yellow sticky note I keep on the monitor?
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
Authentication is a broken concept. Anybody who knows anything about security knows this. Focusing on authorization, not authentication, is the only way to secure anything.
Higher Logics: where programming meets science.
CAPTCHAs can also be used to hide input from hackers: http://ece.uprm.edu/~andre/publications/Khap_scientia.pdf
Nonetheless, a smooth recovery...
Interesting that a first post can be redundant...
I was the person who tagged this "slashdottagsareamystery" and it showed up as a tag. I assume I was the only person who tagged it as this.. I guess i'm just special.. :)
You ARE special.
Just like everybodyu else.
deleting the extra space after periods so i can stay relevant, yeah.
A trackball? Multiple keys? Sure, they got a great idea for selling lots of mouse replacements. And really just for authentication.
How about a biometric scanner? Oh, wait, that's beatable. Iris scanner? Too expensive. And strong passwords really don't work - just have someone steal the database.
It's just stupid.
deleting the extra space after periods so i can stay relevant, yeah.
How can your authorize something, unless you know who you're authorizing?
You've asked the right question. You can find an intro here. That article links to arguably the best authorization scheme: capability-based security, where authorization is combined with designation. This results in many useful security properties that aren't achievable via authentication schemes.
Higher Logics: where programming meets science.
It's about time we start applying better crypto techniques. There is no need to reveal your entire PIN when you use an ATM. For example your PIN could increase by [1 to 32] every time you use it. Now someone needs to observe you twice in a row to get the PIN.
The obvious limitation is the human capacity for math.
Interesting, but I still don't see how that makes authentication unnecessary, at best it just seems another name for it. And I don't really see how it's applicable to everyday tasks such as, for example, access control on buildings or online banking.
THL phish sticks
I didn't RTFA, but it seems as if simply observing the direction of the user's gaze (either informally or possibly with more sophisticated and automated means) could easily betray which of the images is familiar to the user.
This is interesting material, and I'm hoping to find time to research the concepts further.
I have to say, though, that this article doesn't answer such questions as "when I approach a machine, how do I establish the capabilities I need for my tasks to be performed?"
In other words, I can see how this would reduce the roll of authentication during a session of activity, but I do not see in most common use cases how you could start a session without an authentication step. If you can persist your system's capabilities in a way that is portable (with the user) and maintains integrity, that would allow your "session" to be arbitrarily long, but:
1) It would still seem that the decision to initially hand the capability to the user has to be made with knowledge of who the user is, and
2) I'm curious how you would go about restoring security were such a persisted capability stolen.
Let me ask you this: what use is authentication without identity? Identity is generally irrelevant when making authorization decisions, particularly when using capabilities. Identity-based access control is the single cause of our vulnerable computing infrastructure. Identity-based security can be locked down somewhat, with Polaris being the epitome of what's achievable on Windows, but it has fundamental limits associated with the amount of information available to make appropriate authorization decisions.
Capabilities change the whole security game, as they enable principle of least authority designs to be easily constructed. Identity-based controls are not composable, so fine-grained permissions are simply impossible.
Capabilities are not the only authorization-based access control of course, but they are perhaps the most well-known. You can even start playing with capabilities today.
Higher Logics: where programming meets science.
"Anyone who knows security knows this" ...should be read as "anyone who agrees with me knows this". ...should be read as "I'm too ignorant on the subject to comment constructively, so I'll just be flippant".
Higher Logics: where programming meets science.
This seems to provide two thigns:
1) It provides a limited degree of authentication of the machine to the user. This is lacking in, say, ATM transactions today (in the U.S. at least), which is one of the concerns the article talks about. However, while this system has the "side effect" of providing the user with some chance of noticing a fake machine (depending on details of how the system were implemented and deployed), it would be better to approach a design with the specific goal of validating the machine.
2) The point they advertise -- it makes it hard to learn anything by watching the person enter the "password".
I see some challenges, and there are definitely some things it doesn't prevent.
Where do the images come from? Each bank (or other institution using this system) has to come up with a library of images for its users, with each image clearly distinct from the others? But wait -- sometimes I use another bank's ATM. So either (1) the machine will have to start by identifying which bank to use and downloading the appropriate images, which reduces the protection against fake machines; or (2) there will have to be a single library of images for all banks.
In a large-scale deployment, there are additional usability questions that aren't captured by a small-scale trial. If someone sets up different passwords for different systems, will they be able to reliably remember which pictures to use where? What if the systems have similar but different images in their libraries? Keep in mind, human associative memory and visual processing interact in very strange ways sometimes.
How will the visually impaired interact with this system? I think I could use it in spite of my eyesight (barring a really poor implementation), but there are others who can't. I expect that to pretty much end the discussion for me.
My soon-to-be-patented device will banish your arguments one by one: the USB ouija board!
Okay, so I mostly just add "on a network of electronic devices" to existing work. ("USB ouija" return 12 hits on Google!)
I'm sorry, I still don't get it. If person A needs access to some files, and person B must not have access, whatever mechanism is used must be able to differentiate between the two when those files are requested. How do we stop person B imitating person A? Maybe the examples on wikipedia are poorly written, but it still looks like it needs authentication to me.
Do you think this system is also prone to that attack?
1) It would still seem that the decision to initially hand the capability to the user has to be made with knowledge of who the user is, and
You pose some good questions which I intend to address, but first there are a number of assumptions in this one statement which has lead people astray in the past, so I want to address those first.
The User: just about every single access control discussion, particularly informal ones like this thread, start by talking about "users". Talking about "users" quite naturally dovetails into discussions of identities, then authentication, and finally the natural access control abstractions end up looking identity-based like Unix/Windows. The problem with this approach is, users generally aren't a threat. The real threats are from programs.
Access control is mainly about maintaining the integrity of a system in the presence of malicious programs. When viewed this way, identity-based access control starts to look meaningless. The "identities" of programs is a much fuzzier concept than the identities of users, but this is the right way to view access control. You can deal with program identities ala Polaris, and the resulting system is usable, but it's far simpler to eschew identities entirely.
Once you eschew identities, dealing with authorizations as distinct entities looks more natural. The more fine-grained the authorization, the better. Since programs are the only entities handling these authorizations, it doesn't matter how fine-grained we make them. Most of the heavy-lifting is done behind the scenes, hidden from users. When accessing a resource, you have to name it, then provide the authorization token demonstrating you have permission access to it. Then you start to wonder why the designation and the authorization can't be combined into a single handle for convenience. They can! They're called capabilities. Some other designs maintain this separation, but I can't find the reference to the paper at the moment.
Now comes the question: where do these capabilities come from, and how do we get them? The simple answer is: initial conditions. Just like the Big Bang, the universe of objects inside a computer is constructed at installation time. The installer constructs the primordial storage manager, user manager, shell, etc. from which the primordial user can allocate more storage to create other users, and endow them with capabilities, and so on.
At this stage, I've only been talking about programs all contained within a single computer. Now we come full circle to your question: how does someone outside the computer get (re)connected to their session which exists inside the computer? Note first that this is only a problem for a computer shared amongst multiple users.
To maintain the security properties, you need: portable sessions, as you suggested, a portable authorization token, or some form of secure authentication. This is the only authentication step needed, and even then it's not necessarily required.
Your comment seems to imply that an authentication is needed for every interaction with a new object, when you only need to authenticate with one computer, your own, and if you can carry that computer with you (pda, cellphone, etc.), then no further authentication is ever needed. A portable authorization token can be a USB key or a secure card that holds a cryptographically-secure hash designating your session. I prefer the last option, as its the most user friendly, and the most secure.
2) I'm curious how you would go about restoring security were such a persisted capability stolen.
This is a long-standing fear of system administrators everywhere. "Capabilities grant you flexibility and POLA, but you lose control!" There is a thread going on right now on the cap-talk mailing list about this actually. There are many possible ways to address this concern actually, and the only answer t
Higher Logics: where programming meets science.
You think authentication is a "broken concept"?
Authentication - providing proof of a claimed identity
Authorization - managing permissions bound to an identity
See why you need both? You clearly have no idea what you're talking about, whoever you are.
that has been explored in previous research covering similar ideas (they used a stylus input and pressure to hide input): http://www.discover.uottawa.ca/publications/EH2006.pdf
I think the principle of this CMU system is sound. Obfuscating the output and the input for an authentication system is a good approach to limit vulnerabilities to observation. The key is to be able to do it without annoying the user. This scheme seems to be able to make some headway in this regard. However, one aspect I don't like is that it requires a separate hardware solution (i.e. all ATMs would have to have this trackball). If such an investment is going to be made by banks, I figure they would be more inclined to try something else like biometrics. I personally believe this type of input obfuscation can be accomplished with the devices we already have (keypads) and software (I am currently researching this), and thus there would be no added costs (at least additional hardware costs) to implement such a system.
Even in capability-based security, you need strong authentication. Or someone could just log-in as you (the authentication bit) and use your capabilities.
It is true that capabilities bind a permission to an object, so knowledge of the subject by the system is not required to use a capability. This has certain benefits - it's performant, it allows easy delegation or permissions to other subjects, and it avoids the Confused Deputy problem. There are also some downsides to this form of access control - it's hard to contain the spread of permissions outside of a trusted computing base, and it's harder (but not impossible) to revoke permissions once granted.
But this has nothing to do with authentication! You still need it in a capability based system!
I know the work of Mark Miller, Jonathon Shapiro, the E language, Waterken, etc. very well. It's really good stuff, and it has the potential to make more secure systems. However, I'm sorry to say, you've become a "true believer" and this is leading you into making vastly overreaching statements.
Authentication is not a broken concept. Authentication refers to the act of *proving* a claimed identity. Regardless of the authorization model that follows, you have to authenticate at the beginning. Doesn't matter if it's capabilities, access control lists, mandatory access control, whatever. You start with authentication.
Assume that we're in a Java-like language with no static fields or methods. All we have are object instances, and instance methods. Now, let's assume a simple filesystem API for our OS: This package provides very basic filesystem-like services: we can traverse a directory tree, look up names, retrieve subdirectories or files, and open a stream for reading and writing data to files. Let's suppose that the on-disk filesystem looks like this: Now let's suppose that person A and B are modeled by two threads in our OS. We can start thread A with a Directory object which references "/home/A", and we start thread B with a Directory referencing "/home/B". Now show me a sequence of method calls where A can access files under "/home/B", or even the files under "/etc".
Spoiler: no such attack is possible. Our Java-like language is memory safe, so you can't forge a reference to another directory without being given that reference. Object references are capabilities. There is no "getParent()" on a Directory, so a thread, or person, cannot escape out of their home directories. Each directory tree is a private namespace. So how do we enable sharing and document exchange? We map documents into that namespace.
Documents under "/home/B", like "/home/B/homework.doc" look like "/homework.doc" to B. B thinks he's working out of the root directory, and has no knowledge of anything outside of that. Even if he did gain outside knowledge, there's no way to exploit that knowledge. He's constrained by what capabilities he holds, ie. by what references he has. He can only access the objects to which he has references.
For a simple answer to document exchange, let's say we add "/home/A/shared/B", then add a directory entry under "/home/B/A" that points to it. Now A and B have an indirect communication path. Note that we have no notion of "identities", and no separate notion of "permissions" on the files, so your question about impersonation is actually meaningless. If you hold a reference to the object, you can operate on it, no ifs, ands or buts. If you don't have a capability to the object, directly or indirectly, you cannot cause changes to that object. This is capability security. I hope that clarifies things.
Higher Logics: where programming meets science.
Identity is meaningless in a capability system, so it all depends how far down your capabilities go.
Higher Logics: where programming meets science.
Let me pose a hypothetical: consider a capability OS a suspended shell session. Your OS stored a cryptographic token which directly designates that session on a USB key, or a secure crypto card of some sort. Plugging your key into the computer automatically reconnects you to your session. Do you consider this an authentication or an authorization?
Higher Logics: where programming meets science.
"Anyone who knows security knows this" ...should be read as "anyone who agrees with me knows this". ...should be read as "I'm too ignorant on the subject to comment constructively, so I'll just be flippant" is an excellent example of "nested bitching".
up down down right right-left up-down!
Why did I have to pick a high-security 200 BPM password :-(
If I miss one more step, I'll be locked out for a week!
This sounds ridiculously overcomplicated. Where is the innovation in this idea? To me it sounds like any other challenge-response scheme with a layer of arbitrary obfuscation added.
Thanks for the reply; quite informative.
My next round of questions and comments would revolve around the proposition that "the user is generally not a threat". I'd divide the world into two types of system:
The Easy Cases: For some systems, I'd say it's clearly and demonstrably true that programs, not users, are the threat. For example, the WinXP desktop sitting in my office at home isn't under threat from any malicious users (and indeed I don't have it set up to take a password), while systems like it are forever being compromised by malicious programs; so that would seem to be the ideal example for the type of system you describe.
The Interesting Cases: I'm guessing that multi-user networked systems probably present the most interesting (and complicated) discussion. These would include a wide range of cases, from sensitive government/military, to business of various sorts, to research and other university systems. Part of the challenge (at least on the surface) is that in the case of an incoming network connection, the distinction between a "user" and a "program" seems a bit abstract.
I wno't try to go too far into those questions without first checking through the resources you've pointed to, which will take me some time. I would note, though, that many industries operate under regulations that require authentication. This may partially be due to bad assumptions on the part of regulators. However, it also points toward a second reason why people use authentication: Sometimes it's not enough to know that an action is authorized; sometimes you have to keep track of who took each action.
In the simplest case, an employer might grant capabilities to a group of employees so that they can do their jobs. But sometimes trust is misplaced, and maybe one of the employees abuses those capabilities for personal gain (some sort of fraud or theft, etc.). You may not be able to stop him from doing it whether by authentication or by controlling capabilities; the question is, how do you investigate after the fact? The traditional answer is to keep an audit trail -- log that Employee X performed actions A, B, and C at such-and-such time.
So, while you can decouple authentication from authorization to a point, I would still think you'd sometimes have to state "user has provided accurate identification" as a prerequisite of authorization (even if the authorization process isn't looking for any particular identity).
Initially, I was going to call out ATM's as an example of a third category in which the user simply couldn't be trusted; but on reflection, I think this is a matter of perspective. Arguably in the age of electronic transactions PIN's, CC#'s, account/routing numbers, etc. are somewhere between authentication instruments and capabilities as it is; the real question then seems to be what form(s) the authorizing information should take and what means should be used to protect it.
That said, I do think these make up a third category in this sense: Although they may be good candidates for a capability-based system, it remains true that I wouldn't generally "trust" a user as far as I could throw him.
In any case, I plan to look into some of the systems you mention, time permitting.
One insecure password to rule them all!
I think you've gone past the point the other poster was trying to get at. You're talking about a program running on a system. The other poster (and myself now as well) is questioning how does capability authorization allow a user onto a system, in the first place, without authentication. There still has to be some way of identifying the bag of meat that is sitting at the terminal or shelling in remotely.
Just like everybodyu else.
... on the short bus.
Hmm, from my reading, the poster asked an access control question, not an authentication question. To answer your questions, you connect that bag of meat to his session the same way you connect any other piece of software to another remote piece of software: carry an authorization token. I explained one way to make this easy here.
Higher Logics: where programming meets science.
I'm guessing that multi-user networked systems probably present the most interesting (and complicated) discussion.
:-)
If by "multi-user networked systems" you mean systems which host multiple competing interests which are mutually suspicious, then I agree. The vast majority of systems are computer programs communicating with other computer programs, some at the behest of a single user or multiple users, some based on a schedule, etc. If you can solve the problem of safe collaboration among mutually suspicious programs, then any other interaction I can think of falls out as a special case.
Part of the challenge (at least on the surface) is that in the case of an incoming network connection, the distinction between a "user" and a "program" seems a bit abstract.
Exactly, because there is no tangible distinction. Any "user" is communicating with you via some program, presumably under his control. It's programs all the way down.
I wno't try to go too far into those questions without first checking through the resources you've pointed to, which will take me some time.
A good start is Mark Miller's thesis, Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control.
I would note, though, that many industries operate under regulations that require authentication. This may partially be due to bad assumptions on the part of regulators.
Obviously I can't comment on any specifics without researching further, so you could be right. I would be disappointed if such legislation mandated a specific strategy to track information, rather than simply mandate that certain information be available should it be needed.
However, it also points toward a second reason why people use authentication: Sometimes it's not enough to know that an action is authorized; sometimes you have to keep track of who took each action.
Agreed! Delegation control and responsibility tracking are very important, which is why some capability folks designed Horton, which can be viewed as a sort of identity framework built on top of pure capabilities. Identities should only be used for reactive measures however, in case of abuse to identify the offending party and throttle or terminate abuse.
So, while you can decouple authentication from authorization to a point, I would still think you'd sometimes have to state "user has provided accurate identification" as a prerequisite of authorization (even if the authorization process isn't looking for any particular identity).
Whether the user/program intentionally or accidentally leaked his capability, you still have to revoke it to prevent abuse. I'm not sure what authentication gains you here. Identifying the capability is typically straightforward.
That said, I do think these make up a third category in this sense: Although they may be good candidates for a capability-based system, it remains true that I wouldn't generally "trust" a user as far as I could throw him.
Yes, there are no doubt other categories of systems. For instance, the KeyKOS capability operating system was used in early ATM systems starting in the 80s. I'm sure it had something to say on the subject. I hope you have time to research the rich literature of capability access control.
Higher Logics: where programming meets science.
Something I've been considering is the traditional login dialog, where a person is asked 2 questions: username and password, and always in that order. It's so ubiquitous it seems people don't think twice about it, and for some time now have been confusing the purposes of the two. I looked into the history of the login dialog, and learned this practice of asking for both username and password goes all the way back to the very first multiuser operating system, CTSS, in the early 1960s. You'll see solemn assertions that you have to keep your username secret to maintain your security. And, sadly, that's true. A trick that the security folks have been playing on users is bolstering weak passwords by using the username in an authentication process. As another person put it, it's annoying to have your password entry broken into two fields. That seemingly makes authentication more secure, but the price has been confusion as demonstrated by all this advice about keeping your username a big secret, and all these uses of the username that require that to be public knowledge. I've also seen quite a few systems that suggest users should use their email address for their username. And there is also confusion in that probably just about everyone unthinkingly assumes authentication is required to make access secure. So in some cases they've kinda worked around the problems by in effect giving everyone 2 identities. Messy. I think systems should be designed so that to login, users enter a password only. Of course, the system would have to generate at least part of all passwords, to guarantee that they are all unique.
For those who write authentication programs, a basic security mistake that shouldn't be a mistake is the idea of rejecting a login attempt after a username but before a password is entered. Well of course a password shouldn't be rejected before the entire thing is entered.
You don't identify yourself to a car, you simply use a key (password), the car doesn't care who you are, nor does it need to. You can give out copies of the keys or loan the keys to someone else so they can drive your car. Same goes for the combination to a combination padlock for a bicycle-- the lock doesn't care who anyone is. Have I understood what you're getting at, naasking? Capability based security is much like password only access? Like keys to a car?
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
That is a more interesting thought experiment. I would say the user authenticates to the system using the token - something the user has. The purpose is only to (indirectly) identify the user (as opposed to any other user), to allow them to keep using their session.
Having said that, you are using a capability authorization mechanism to perform authentication. Which demonstrates how flexible and useful this mechanism is - but I still say the process looks like authentication, and behaves like authentication, therefore...
The example does blur the line quite nicely though. Thanks for posting it.
You don't identify yourself to a car, you simply use a key (password), the car doesn't care who you are, nor does it need to. You can give out copies of the keys or loan the keys to someone else so they can drive your car. Same goes for the combination to a combination padlock for a bicycle-- the lock doesn't care who anyone is. Have I understood what you're getting at, naasking? Capability based security is much like password only access? Like keys to a car?
You pretty much have it. The "capabilities as keys" analogy has been used extensively before, and its accurate to a first approximation. Capabilities have stronger security properties than keys though, so don't take the metaphor too far. Here's a paper discussing the various forms of capabilities and debunking the myths promulgated about them over the years.
And using only a password to authenticate is also a good idea, provided the password is a cryptographically secure identifier.
Higher Logics: where programming meets science.
I would say the user authenticates to the system using the token - something the user has.
But if this token were a YURL, ala Waterken web-calculus, then it's actually considered a capability. I think the correct way to look at it, is an authorization with an authentication step. Whatever system you plug it into must validate the token to ensure it names a resource on the current system (a sort of authentication), then invoke that resource to resume the session. YURLs go through this same process, as all services must validate data from untrusted sources. I think the important property is that it behaves like a capability to the user, so I'm not sure that it behaves like an authentication as you say.
Higher Logics: where programming meets science.
Well, we're clearly coming from different perspectives on this one. I don't deny that it *is* a capability - but I would assert that it is being used as part of an authorization process, which is how the security it provides would be judged.
In terms of a security risk analysis of this system, I would want to know the strength of protection that this system allows for its users and the content being protected. The system gives two "authorization" paths to access the resources of a user: (1) log in with a password (2) use the USB key to recover a session. From my perspective, I don't care about the underlying mechanisms - I want to know that all the paths meet a minimum security standard.
Taking this experiment a bit further: the username / password combination is probably cryptographically less secure than the random token (assuming it using a random "swiss" number of sufficient length). However, most username/password authentication mechanisms will lock out the user after several wrong attempts. The cryptographic token doesn't do this, allowing for online, rather than off-line brute force attacks. We may conclude that this doesn't really matter. Further, we may ask: is it acceptable that mere possession of the token is sufficient to access the session? Many token-based authentication mechanisms also provide for a PIN or "something you know", to prevent accidental loss or theft of a physical item compromising everything. If we want this facility to comply with our security standards, then you will have to add this mechanism to your capability - maybe the session capability merely gives you a capability to enter a PIN, which if correct (say 3 guesses allowed), will unlock the session. So we can still use a capability mechanism - but note that we are designing an authentication mechanism.
All of this security analysis is done on the basis that what is being provided is an authentication process The underlying mechanism is irrelevant to the consideration of the risks and how it will be viewed in any real-world implementation.
Freudian slips! "but I would assert that it is being used as part of an authorization process, which is how the security it provides would be judged." and "The system gives two "authorization" paths"
I meant to say "an authentication process" and "authentication paths"!