New Authentication Scheme Proposed 102
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 (Score:1, Insightful)
Re: (Score:2, Informative)
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Then again, I'm pretty paranoid about ATM use. Typically, I only go to the one at my bank, and I check it for signs of tampering before I use it. I'm familiar with the machine, so I'm hoping that if an outer casing was placed on top of it, I'd notice.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
ps. Also, i left out the "profit" step
Re: (Score:2)
(I did the same thing once btw, don't feel bad
Perfect solution. (Score:1)
Not only is it obvius how to crack it ... (Score:1, Offtopic)
For increased portability... (Score:5, Funny)
When the user is asked to enter their password they enter the booth, shut the door and strut their funky password.
Re: (Score:2, Funny)
Me(from within the booth after 5 minutes of dancing): Ssssh, I'm trying to concentrate - this is the best part!
mod parent up ... (Score:2)
3 factor authentication and one time pad (Score:2, Informative)
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 :)
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:2)
Enter your PIN on the fob, get a code. Swipe your card, enter your card's PIN, enter the PIN from your fob, and you're in. To make it easier on the user, allow them to enter the PINs in any order.
Most users will use the same PIN for both devices--that's their fault. Some users will enter their fob PIN in full view of the security camera--again, their fault. At least people who care about their information will be capable of doing it securely, unlike the current
Keypad (Score:5, Interesting)
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.
Re:Keypad (Score:5, Funny)
on the upside, you get to set your own hours.
Re: (Score:2)
Never mind, you were pretty much on the right track...
Re:Keypad (Score:4, Funny)
GrIDsure Re:Keypad (Score:1)
Re: (Score:1)
Telling you they thought they knew the code was stupid... unless it was misdirection to cause the guards to change their behavior because they knew you'd tell the guards.
Re: (Score:1)
By and large I've found that the reason we say crime doesn't pay is that we only catch the dumb ones.
As I like to say, "crime doesn't pay, but only because when it does we call it politics."
Re: (Score:2)
Re: (Score:1)
They lasted less than a month. We had quite a few blind students who really didn't like the system.
Of course if you had dynamic brail buttons...
D
Re: (Score:2)
Except that they gave everybody and their brother the code.
And over the two years I was there, it was never changed.
Small sample size (Score:2, Interesting)
!security (Score:1)
This would NEVER work out (Score:3, Insightful)
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.
work around (Score:1)
Okay, so I mostly just add "on a network of electronic devices" to existing work. ("USB ouija" return 12 hits on Google [google.com]!)
Rotating keypad (Score:1)
Re: (Score:2)
If your attacker can install software on the machine (e.g. keylogger), then they can just install a screen recorder and set it to run whenever certain software is run (such as your rotating keypad program). (That would be to limit the amount of crap that has to be saved).
Oh well.
Re: (Score:2)
Overly complicated (Score:4, Insightful)
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.
Re: (Score:2)
For one thing, I don't think you could could fool this with a gummy bear.
This isn't that new... (Score:1)
Re: (Score:1)
Lego Mindstorm? (Score:1)
Yeah, but the real question is... (Score:5, Funny)
The problem with authentication is authentication (Score:3, Insightful)
Re:The problem with authentication is authenticati (Score:4, Insightful)
Re:The problem with authentication is authenticati (Score:4, Informative)
You've asked the right question. You can find an intro here [wikipedia.org]. That article links to arguably the best authorization scheme: capability-based security [wikipedia.org], where authorization is combined with designation. This results in many useful security properties that aren't achievable via authentication schemes.
Re: (Score:2)
Re: (Score:2)
C
Re: (Score:2)
Re: (Score:2)
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:
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
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 as
Re: (Score:2)
You pretty much have it. The "capabilities as key
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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 cap
Re: (Score:3, Interesting)
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
Re: (Score:2)
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 ar
Re: (Score:3, Interesting)
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 p
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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 authenticati
Re: (Score:2)
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 ser
Re: (Score:2)
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 p
Re: (Score:2)
I meant to say "an authentication process" and "authentication paths"!
Re:The problem with authentication is authenticati (Score:1)
Re: (Score:2)
Anybody who knows anything about security.... (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Even
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
This idea is stupid. (Score:2)
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.
Just use Crypto (Score:1)
The obvious limitation is the human capacity for math.
Perhaps an overstated case... (Score:2)
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 machi
This is an interesting idea... (Score:1)
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
Re: (Score:3, Funny)
That's what I get for posting at 5:30am before I've had my caffeine.
Re: (Score:2)
Re: (Score:1, Offtopic)
Re: (Score:2)
Just like everybodyu else.