Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Hardware

New Authentication Scheme Proposed 102

Posted by Soulskill from the more-secure-less-portable dept.
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."
This discussion has been archived. No new comments can be posted.

New Authentication Scheme Proposed More

New Authentication Scheme Proposed

Comments Filter:

  • And within a month (Score:1, Insightful)

    by dreamchaser ( 49529 )
    And within a month, someone will figure out a way to crack it. It's inevitable.

    • Re: (Score:2, Informative)

      by morgan_greywolf ( 835522 )

      And within a month, someone will figure out a way to crack it. It's inevitable.
      Obvious. It's vulnerable to some of the same techniques that passwords are vulnerable -- sniffing (assuming no encryption was also used), man-in-the-middle, keyboard (mouse) sniffer, malicious code, etc.
      • On the other hand, it has it's uses. There's not much reason why I should have to press my PIN into a publicly visible terminal when I use an ATM.

        • On the other hand, it has it's uses. There's not much reason why I should have to press my PIN into a publicly visible terminal when I use an ATM.
          Thieves could just setup a digital camera at a commonly-used ATM, and then capture all the pictures. Eventually they'd figure out which ones belonged to which users.

          • Re: (Score:2)

            by mrxak ( 727974 )
            They still need to steal your card though, and unless you're pretty careless you'll notice when they do, and then you can call your bank and have your card deactivated. This strikes me as a little less secure than an ATM.
        • If you have one, you can use your wallet to cover your hand and the keypad.

          • Re: (Score:2)

            by Sancho ( 17056 )
            I do this. My right hand types in my PIN, while my left hand provides cover. I get funny looks from people who are nearby, but that just justifies me.

            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.
    • Maybe using directional microphone to listen for characteristic noise of vibrating trackball? See, you didn't have to wait whole month.
    • Hasn't this problem been solved already with two-factor authentication? You have a token that has a short numeric code that changes every minute or so, and your password is a combination of a secret PIN and the number on the device. Or, for the poor-man's-version, you have a series of one-time PINs written down (or printed out) so that the credentials you use to authenticate yourself can only be used once. I have been using a system like this on one of my servers for a couple years now. One major limita
  • For all those hackers lined up behind me, looking into my monitor!

  • ... but I HATE trackballs!

  • For increased portability... (Score:5, Funny)

    by sakdoctor ( 1087155 ) on Friday February 08, 2008 @09:35AM (#22347586) Homepage
    ...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.

    • Re: (Score:2, Funny)

      by Tolkien ( 664315 )
      Employer: Is your password really that long? Come on! Hurry up and finish already.
      Me(from within the booth after 5 minutes of dancing): Ssssh, I'm trying to concentrate - this is the best part!
    • up down down right right-left up-down!

  • 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)

      by Anonymous Coward
      Wouldn't that only be two factor authentication? Username and password only count as one factor (something you know) and the pad is the second factor (something you have.) In order to be three factor you would also need something you are.
    • This is for ATMs, so the "thing you have" is the card rather than a one-time-pad, but otherwise and it works pretty much as you describe. The need for a different "password" entry system is that it's trivial to shoulder-surf a PIN and then obtain the card by distracting the person and taking their card as it is ejected from the machine, picking their pocket, stealing their bag, beating the crap out of them...

      • Re: (Score:2)

        by Sancho ( 17056 )
        This is why a security fob would be useful.

        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)

    by mpickut ( 721322 ) on Friday February 08, 2008 @09:38AM (#22347608)
    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.

    • Re:Keypad (Score:5, Funny)

      by anothy ( 83176 ) on Friday February 08, 2008 @09:57AM (#22347722) Homepage

      my job takes me in and out of jails frequently
      yeah, that and the early burnout are the two big problems with a career in the narcotics trade.

      on the upside, you get to set your own hours.
      • Hey, he (?) may not be a drug dealer. He might be a lawy...

        Never mind, you were pretty much on the right track...

        • Re:Keypad (Score:4, Funny)

          by mpickut ( 721322 ) on Friday February 08, 2008 @11:30AM (#22348830)
          Don't you dare call me a lawyer! We heroin addicts have enough of a image problem without being linked to those soulless drains upon society. At least if you made heroin legal we would stop stealing and stay to ourselves.

    • 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.

    • Re: (Score:1)

      by MrMonty ( 366322 )
      I bet some of those guards say the numbers to themselves as they type them in and wouldn't be too tough to read their lips. That idea came to me in a matter of seconds. Now imagine you're in jail and have practically all day to think of other, more creative methods of getting the code.
      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 mpickut ( 721322 )
        No, they were just stupid.

        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."

    • (my job takes me in and out of jails frequently)
      Burglar?
    • They brought them in to my college (more than a few years ago)

      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)

      by jafac ( 1449 )
      Yes; I know of a keypad like that, used at a former employer, as well. Very secure.

      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)

    by ssjx ( 1235532 )
    They seem to have big plans for this yet have only tested it with 38 users?
  • 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 would NEVER work out (Score:3, Insightful)

    by brunes69 ( 86786 ) <`gro.daetsriek' `ta' `todhsals'> on Friday February 08, 2008 @09:57AM (#22347730)
    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.

    • My soon-to-be-patented device will banish your arguments one by one: the USB ouija board [wikipedia.org]!

      Okay, so I mostly just add "on a network of electronic devices" to existing work. ("USB ouija" return 12 hits on Google [google.com]!)
  • 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.
    • Screen recorder.

      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.
      • If you have managed to install a program on an ATM then I don't think you need to bother with any program other than one to operate the bit where the money comes out..? I have been saddened and amused before upon seeing ATMs with BSODs, and one with a Windows desktop on it. I thought that they'd use custom systems..

  • Overly complicated (Score:4, Insightful)

    by ddrichardson ( 869910 ) on Friday February 08, 2008 @10:08AM (#22347822)

    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.

    • I can't see what this does that a fingerprint scanner doesn't.

      For one thing, I don't think you could could fool this with a gummy bear.

  • 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.
  • Okay, I guess that is slightly more useful than what I've used my Mindstorm kit for.

  • Yeah, but the real question is... (Score:5, Funny)

    by Prototerm ( 762512 ) on Friday February 08, 2008 @10:21AM (#22347946)
    Would I be able to still fit my password on that yellow sticky note I keep on the monitor?
  • 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.

    • Re:The problem with authentication is authenticati (Score:4, Insightful)

      by Psiren ( 6145 ) on Friday February 08, 2008 @11:18AM (#22348680)

      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.
      How can your authorize something, unless you know who you're authorizing? The two go hand in hand, I can't see how you can have one without the other.
      • How can your authorize something, unless you know who you're authorizing?

        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)

          by Psiren ( 6145 )
          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.

          • Re: (Score:2)

            by naasking ( 94116 )
            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 [hp.com] 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 [wikipedia.org].

            C

            • Re: (Score:2)

              by Psiren ( 6145 )
              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.

              • Re: (Score:2)

                by naasking ( 94116 )
                Being used to identity-based access control, it's difficult to imagine another way. I just posted this elaborate response [slashdot.org] to another question, but perhaps it's a little too abstract. I'll assume you're a programmer. I'll further assume that you're familiar with Java.

                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:

                package Filesystem;

                public abstract class Entry {

                • 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.

                  • Re: (Score:2)

                    by naasking ( 94116 )
                    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 [slashdot.org].

                    • 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)

                      by naasking ( 94116 )
                      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 key
            • 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

              • Re: (Score:2)

                by naasking ( 94116 )
                Identity is meaningless in a capability system, so it all depends how far down your capabilities go.

        • Re: (Score:2)

          by mea37 ( 1201159 )
          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 cap

          • Re: (Score:3, Interesting)

            by naasking ( 94116 )
            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

            • Re: (Score:2)

              by mea37 ( 1201159 )
              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 ar

              • Re: (Score:3, Interesting)

                by naasking ( 94116 )
                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 p
        • 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

          • Re: (Score:2)

            by naasking ( 94116 )
            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?
            • 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 authenticati

              • Re: (Score:2)

                by naasking ( 94116 )
                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 ser
                • 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 p
                  • 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"!

    • "Anyone who knows security knows this"

      ...should be read as "anyone who agrees with me knows this".

      • Re: (Score:2)

        by naasking ( 94116 )
        "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".
    • 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.

      • Re: (Score:2)

        by naasking ( 94116 )
        Then perhaps you should get a better dictionary [reference.com]. There is more in heaven and earth Horatio, than is dreamt of in your philosophy...
        • Well, as I've said above, I know capability based access control very well. I nearly did my MSc degree dissertation on it, specifically the work of Mark Miller on the E language and distributed capabilities. But your original statement about authentication is still wrong. You still need good authentication in a capability based system. Authentication and authorization are not alternatives to one another!

          • Re: (Score:2)

            by naasking ( 94116 )
            I never said they were alternatives, I said you didn't need authentication, and that authorization was sufficient. I'm not a shmuck who's been drinking too much of the capability kool-aid; I know authentication can be quite useful in some situations, and is an integral part of many existing systems. However, I believe authentication draws far too much attention when it's really a trivial problem. We know 10,001 ways to authenticate anything, but it doesn't help because authentication is not the problem.

            Even
        • I will concede that "managing permissions bound to an identity" isn't a great definition. The permissions themselves don't need to be bound to an identity, as capability systems demonstrate very well. A better definition might be "managing the association of permissions with an identity". Taking a very granular view, in an object based capability model, each object has an identity. Regardless of how they are bound, would you agree that authorization is about moving permissions around things that have id

      • Re: (Score:1)

        by Follis ( 702842 )
        I think what you may be overlooking is this fundamental question. What's the difference, to a computer, between me, and a program which acts _exactly_ like me? The answer is: none. Therefore the dichotomy between users and processes is, from the above perspective, false. It has already been well established that you can "clone" processes. The combination of the two makes "identity" a relatively useless concept. Alternately you can view "authorization" as an easily forged (read useless) capability. Concatena
        • Well, you are always just a process to the computer! One that represents you. The point of authentication is to prove your (the process that represents you) right to use a user-account to the computer in a way that only you could. This could be a secret (something you know), a token (something you have), or a biometric (something you are). Identity is definitely a slippery concept when you get down to it, but it's not a useless one. Of course, your slashdot password and username doesn't really identify

          • Re: (Score:1)

            by Follis ( 702842 )
            Sorry, I should have been a bit more clear. Authorization is easily forged compared to say a really large random number space. As far as authentication being a weak capability, the address of the machine represents the object, under authorization the action(s) you can perform are the challenges + your responses.
  • 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.
  • 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.
  • 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 machi
  • 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 [uottawa.ca]

    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

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close