Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Security Communications Technology

Moving Beyond Passwords For Security 235

Naturalist writes with an excerpt from a New York Times story about the need for a more secure method for identification than the password-based system almost everyone currently uses. The article also discusses the weaknesses of the OpenID initiative to simplify the process. "The solution urged by the experts is to abandon passwords -- and to move to a fundamentally different model, one in which humans play little or no part in logging on. Instead, machines have a cryptographically encoded conversation to establish both parties' authenticity, using digital keys that we, as users, have no need to see. ...OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else's Web site. Nevertheless, every few months another brand-name company announces that it has become the newest OpenID signatory."
This discussion has been archived. No new comments can be posted.

Moving Beyond Passwords For Security

Comments Filter:
  • Yes, we know. (Score:5, Insightful)

    by Anonymous Coward on Sunday August 10, 2008 @02:50PM (#24547771)

    The solution is public key cryptography. The problem with that solution is that it only works as "something you have", not "something you know", which is the authentication mode of passwords. You can't leave "what you know" at home, but will you always have your smart card with you? Another problem is that secure public key cryptography requires a complete terminal under the control of the user, not just a card. The private key can never leave the user's control and the user must always know what it is used for. That requires a display and keyboard. Not something people want to have on them whenever they need to authenticate.

    • Why not send authentication query via SMS or standard phone lines? No keyboard required.

      • Re:Yes, we know. (Score:5, Insightful)

        by Kjella ( 173770 ) on Sunday August 10, 2008 @03:01PM (#24547873) Homepage

        Yes, if you're always where there's phone coverage and you got battery. However, it doesn't solve the problem of a compromised terminal. That was what a bank virus did not that long ago, waited for the user to authenticate then sent money elsewhere "behind the scenes". Sure it might not get your email password but if it silently downloads your inbox compromising every password mail you ever got, well gee that's nice.

      • Re: (Score:3, Interesting)

        by GuldKalle ( 1065310 )

        It's an ineffective way of using your phone as "something you have".
        I propose installing a program + private key on your cellphone, and use that to encrypt a random token. Then you get a hash of the ciphertext on the cellphone display, which you enter in order to login.
        It could even be nicely integrated into openID, bringing me to my next point:
        The thing I just mentioned CAN be made by an openID provider (I was surprised that I couldn't find such a provider though), and it would make a lot more sense to mak

    • by ratnerstar ( 609443 ) on Sunday August 10, 2008 @02:55PM (#24547821) Homepage
      It can work as "something you know," all you have to do is memorize your private key. Kids these days; they want everything to be easy.
    • Re:Yes, we know. (Score:5, Interesting)

      by jd ( 1658 ) <imipak AT yahoo DOT com> on Sunday August 10, 2008 @03:55PM (#24548383) Homepage Journal

      The US Government uses this method, except via smart cards. This started with the NMCI initiative. I was not keen on NMCI, as it used Citrix and centralized application serving. This creates a single point of failure (which quite often failed at the beginning) and a single, all-powerful account on a system (there's no other way of having a central system responsible for all privileges otherwise) on an operating system that probably isn't going to be in the Trusted class (ie: it ran Windows - and I am using the Trusted class in the Orange Book sense, not in any "popular" sense of whether people actually trust it).

      PKI is a very sensible approach, but should not be used in isolation. This was discussed only a short time ago on Slashdot regarding "secure locks" - there should always be multiple layers of security, a reliance on a single layer is always going to be a disaster waiting to happen.

      Passwords as a "bootstrapping" mechanism to enable the rest of the security sounds fine. It's something we already do with regards GnuPG/PGP keys, Kerberos, etc. They're weak, but bootstraps don't need to be that strong if you're using them in a multi-layer system. They're supposed to make it hard for anyone to tell if they've broken the other layers. That is sufficient.

      There is, however, almost nothing else you can use. Biometrics are not safe (Slashdot has covered the breaking of many such systems) and not guaranteed to work (Slashdot has covered chimeras and other biological weirdness in the past). Two physical electronic keys won't give you significantly more security than one with twice the quality of encryption and just give you more you can lose. Call-back mechanisms are vulnerable to social engineering (if involving people) or replay attacks (if automated) since such methods have to use extremely primitive security as they are prior to authentication.

    • Re:Yes, we know. (Score:4, Interesting)

      by JFitzsimmons ( 764599 ) <> on Sunday August 10, 2008 @04:41PM (#24548737)

      And you can do that with openid. I got bored and made myself a GPG based openid provider. It isn't complete by any means since it lacks key revocation and such, but it is working and public. []

    • by pointbeing ( 701902 ) on Monday August 11, 2008 @06:35AM (#24553589)

      I work for an agency under DoD and have had what they call a Common Access Card (CAC) for more than three years.

      Leaving my CAC at home has never happened to me but I imagine the experience would be fairly uncomfortable as the CAC is also used for building access - someone would have to sign me into the facility if I forgot my smartcard. I don't imagine I'd have to be embarrassed that way more than eight or ten times for it to sink in that I need to keep my smartcard with me ;-)

      Humans (at least most adult humans) are conditioned to carry their driver's license with them when they operate a vehicle so learning to carry a smartcard with you wouldn't be all that difficult. To address the issue of requiring a keyboard and display (and a smartcard reader) there are contactless smartcards available and I *think* the technology's compact enough to include in a cell phone or other device.

      IM frequently less than HO physical security will always be paramount - a physical token requires a user to have both the token and the PIN to that token to access a protected resource. In this agency there have been a few misplaced smartcards but there hasn't been one instance of a protected resource compromised because a bad guy had both the user's CAC and the PIN to it.

      People tend to write down "what they know" if it's fairly complex - which compromises physical security. All I have to remember is an eight character PIN. My PC will lock my CAC after three unsuccessful PIN entries, which requires me to visit the card issuer to have my PIN reset.

      All in all it's been fairly secure and easy to use. The transition to smartcards hasn't been completely painless but these days I use the card for building access (I have access to the raised floor area in the basement), to the network (smartcard authentication to the network is mandatory), to secure websites hosted on the network that use CAC authentication and to government-only applications that ping your smartcard to see if you're supposed to be running that application.

      All in all it's been a pretty good thing and I was originally one of the naysayers on the project.

  • "Beyond Passwords" (Score:4, Insightful)

    by apoc.famine ( 621563 ) <> on Sunday August 10, 2008 @02:54PM (#24547817) Journal
    I do not know that this is an accurate title.

    Users on shared systems can easily set up a simple PIN code to protect any card from use by other users...

    That almost sounds like a....password...

    Really, this is an article about using things instead of passwords....which function like passwords....and using passwords when those wouldn't be secure enough. What a stupid fucking article.

    • Re: (Score:2, Interesting)

      by bjustice ( 1053864 )
      Did you read the next paragraph, or understand the rest of TFA?

      The PIN doesn't return us to the Web password mess: it never leaves our machine and can't be seen by phishers.

      • It's still a password. It's a password that is used for authentication in a different way, but it does not move us "beyond passwords for security"

        • by LO0G ( 606364 ) on Sunday August 10, 2008 @05:43PM (#24549273)

          You're right. It IS a password. And it doesn't matter.

          The PIN is a password that unlocks the smart card. In order to authenticate with the remote server, you need both the PIN and the smart card.

          It's called two factor authentication. There are essentially 3 types of authenticators:
          1) What you know (a password)
          2) What you have (a key or a smart card)
          3) What you are (fingerprint or retina scan).

          Most web sites use one factor authentication - their security depends only on what you know (your password).

          The primary attack that's involved here is an attacker attempting to guess/steal your password to a remote site. All they need to know is your password and they're in. And they can take your authentication information and use it from any machine on the internet - thus they can sell your identity and make money from that.

          With a smartcard/pin combination they need both the PIN (what you know) and the smartcard (what you have). The PIN is totally useless to the attacker unless they also have the smartcard.

          Adding the second factor to the authentication system does move "beyond passwords".

      • by khasim ( 1285 ) <> on Sunday August 10, 2008 @03:17PM (#24548015)

        With Kerberos, your password never leaves your machine.

        The machine you're trying to log on to sends you a random string that is encrypted with your password.

        Your machine uses the password you typed in to decrypt that string. Which also contains instructions on how to continue the connection.

        Your password never goes across the wire.

        • Hell, even NTLM did that years ago.. it's not rocket science.

          The problem is websites that want 'pretty' login screens with text boxes for input, instead of using the builtin authentication methods available over HTTP. It's not uncommon at all for this to be done on unencrypted pages (even some banks have made that mistake).

          • by bucky0 ( 229117 )

            I know very little about HTTP AUTH, but wouldn't an easy solution to this be to allow other authentication mechanisms to be submitted with a form?

          • Re: (Score:3, Informative)

            by huge ( 52607 )

            The problem is websites that want 'pretty' login screens with text boxes for input, instead of using the builtin authentication methods available over HTTP.

            Exactly, why to expose your own code to all the automatic probes that go around the internet when you could use "well-tested" webserver code instead? If there are problems with webserver authentication code somebody might patch it but if it's your own code nobody but you will be auditing it.

            Sure, your authenticated users could still exploit your code once authenticated but that would at least limit the number of attempts.

            It's not uncommon at all for this to be done on unencrypted pages (even some banks have made that mistake).

            It's worth noting that HTTP Basic Authentication just base64 encodes the passwords but

        • how does the machine know what your password is to do the encryption on the string before it sends it if you never sent it over the wire? or is this like public/private key exchange? Something like Diffie-Hellman? []
        • Except this means the server can't store your password as a hash... it has to store your actual password, which means if someone gets access to that server they can steal all the passwords.

          The server can encrypt the passwords, but it has to be able to decrypt them, so it needs to know the decryption key too. Which can also be stolen the same way.

      • by bogado ( 25959 )

        PN usually are passwords, but they are simpler and unique (some user have a single sign on, but this is a bad practice).

    • someone, preferably in NY, should call them up and explain they don't know what they're talking about. i wonder how much they'd pay for a proper article putting the OpenID story straight?

  • by blahplusplus ( 757119 ) on Sunday August 10, 2008 @02:56PM (#24547829)

    Passwords can still play a role, the problem has always been user stupidity and convenience vs security. We always love to save time and anything that requires less effort = good for us, but at the expense of being less secure. Moving security to invisible layers is just asking for abuse by authorities, as if they didn't have enough power already via MAC address + ip binding in being able to track down and identify users by merely tooling around with the equipment right at the ISP end.

    My bank uses multiple authentication using personal questions which I would only know the answer to and if you get the question wrong just once, it flags the account. The big problem is the amount of retries, you can't guess or brute force passwords on accounts that will lock after the first few failed attempts.

    In my opinion it's probably best if we moved to gesturing, I find an interesting site here - []

    It could serve as an interesting basis for security, i.e. gesturing and opening the correct doors in a maze.

    • by Saishu_Heiki ( 969303 ) on Sunday August 10, 2008 @03:12PM (#24547967)
      Security versus convienience has been a large issue here at the hospital where I work in the IS department. Because all of the pharmacy orders are done in our clinical application, the state pharmacology board mandated that another layer of security be added beyond the physician's username/password. The result is a list of 60 person questions (hometown, number of brothers, country of birth, etc) that is drawn from randomly to ensure the person ordering the drugs is the one who is logged in and authorized. The problem was, doctors were answering "1" to all 60 questions so they would not have to remember the answers or be bothered actually reading the questions. If they had to use their ID badges instead, it would be an even bigger nightmare. They want speed and ease of use, but are reckless because data security is "my concern". Sometimes it is hard to stop the person with the gun to their head from killing themselves, regardless of whose responsibility it is.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      The one thing that has always bothered me about retry lockouts is the denial-of-service opportunity. If someone knows your username, then they can harass you by expiring the retry limit. Even worse, they can let a bot do it. They won't brute-force your account, but they can ensure that logging in yourself is a huge headache.

      Perhaps a modification to the retry lockout strategy would be to make it per-IP address. It would shift the danger to large botnets, which could still distribute the password atte

      • "Of course, now this makes processing logins expensive, as each attempt requires consulting with a retry-blacklist. One might try making a single, global blacklist and then dealing with the support calls from people with infected machines who were blacklisted for testing other accounts without their knowledge.

        Tough game to win, really..."

        Well this is why banks could keep a record of IP's you login from and only block permanently those that according to the logs are rarest in successful login attempts.

    • It could serve as an interesting basis for security, i.e. gesturing and opening the correct doors in a maze.

      I like that idea, especially if whoever sets up the gestures has a bit of imagination and a sense of humor. I'd love to be able to open a door just by walking up to it, holding my left hand up at shoulder level and snapping my fingers. Clapping my hands three times at waist level would be another neat idea. Set it up right, and it would feel like you were in a magician's lair, and that there were

  • by Anonymous Coward

    I like that slashdot hides your password if you accidently type it into a comment.
    Look: **********

  • PEBKAC (Score:5, Insightful)

    by at10u8 ( 179705 ) on Sunday August 10, 2008 @03:01PM (#24547871)
    Problem exists between keyboard and chair, and the article does not address that aspect nor give any good workaround.
    • Re:PEBKAC (Score:5, Insightful)

      by houghi ( 78078 ) on Sunday August 10, 2008 @05:40PM (#24549243)

      Indeed PEBCAK, because it is my fault that I have all these logins that I need to remember.
      Let me see? I have about 12 different logins that I was not allowed to select myself. Of those there are 6 that I can not change the password. These are just the ones I use at work and do not include the once that are not personal, but are group login and passwords.
      The other 6 I must change every month and to nt get mixed up, I use something easy to remember. And I have worked in worse places. One where I needed to change my password each week for certain access. So I started to write them down.

      If that is PEBCAK, then so be it. It might just be my naive idea that if many people have an issue with e.g. a procedure, then it is not the people who need to change, but the procedure.

      If you see that nobody can reach the peddles on his bycicle, don't ask for taller people, start making smaller bycicles.

  • OpenID (Score:5, Insightful)

    by Cyberax ( 705495 ) on Sunday August 10, 2008 @03:02PM (#24547883)

    OpenID is _PERFECTLY_ compatible with passwordless authentication. For example, my OpenID provider uses Kerberos authentication.

    I too feel that passwords are too weak. Something like special hardware tokens are much better, but there's no infrastructure for their distribution.

    • by h4rr4r ( 612664 )

      That is something held, not something known. Someone can take your something held. Ideally you would have both.

      • Re: (Score:3, Insightful)

        by Cyberax ( 705495 )

        For most applications "something held" (maybe with a simple PIN-protection) is perfectly fine. Like your keys, for example.

        Good key revocation system is essential in this scenario, however.

        Passwords are much overrated, anyway. Most users inevitably either choose weak passwords or just write them down somewhere.

        • by h4rr4r ( 612664 )

          A PIN is a password. So you are saying something held is fine, if you have something known too.

          My car has a much easier known-exploit, the infamous rock to window method.

          Written down passwords are not inherently bad.
          If they are kept in a safe place, say a wallet, and they are not marked as to what they are for it can be an acceptable practice. Especially if very few attempts are allowed.

          • by Cyberax ( 705495 )

            A PIN is a weaker form of password. It also relies on hardware (to lock you out if you enter PIN incorrectly several times). It's useful to make simple attacks (like stealing your token) harder.

            A written-down password is less secure than a hardware token. Because you can simply copy the written password (and use it later) but you need to have a physical token to use it. Of course, assuming tokens are not easy to clone.

          • My bank has quite a good solution. They provided me with a pin pad, which i use in combination with my (chip&pin) bank card. When I need to make a transaction online, I am presented with a code. I enter this into the pad along with my pin, and it produces another code, based upon the key held in the chip. This can also be used for identification by producing a time-based code similar to RSA keys.

      • Re: (Score:3, Informative)

        However, "something held" can be considerably more secure than "something known".

        Either way, the point is that TFA represents OpenID as a reduction in security, when, in fact, it allows you to implement whatever security measures you want.

        This is a common misconception -- that OpenID is simply single-sign-on in new clothes. It's actually an opportunity to give the user responsibility for their own security, and that's a powerful thing.

      • Somthing held = a card with 1000 5 letter sequences.

        Something known = The "algorithm" you change those 5 letter sequecnes:

        copy the last two letters, in reverse order to the front. Add the two digit day of the month (or minute) to the end.

        The host chalenges with a number: 567
        You look up "SBEce"
        You key in "ecSBEce10"

        Possible Changes:

        copy or move:2

        To the beginning or End:2

        First two
        center three
        last two
        first three
        last three:5

        Reversing them or not:2

        add 2 digit minute
        add 2 digit day"2

        To the beginning or end:2

        add t

    • Re: (Score:3, Insightful)

      by Colin Smith ( 2679 )

      Something like special hardware tokens are much better, but there's no infrastructure for their distribution.

      They're also not cheap.

      • by Cyberax ( 705495 )

        There's no real reason for it.

        They are expensive because demand for them is low and economy of scale doesn't have a chance to kick in.

        Combine it with a lot of conflicting proprietary implementations.

    • Re:OpenID (Score:4, Interesting)

      by CTachyon ( 412849 ) <(ten.noyhcat-sonorhc) (ta) (sonorhc)> on Sunday August 10, 2008 @03:10PM (#24547947) Homepage

      Also, many OpenID providers like MyOpenID [] let you generate a browser-side SSL certificate and forbid password logins entirely on your account. At that point, you can't be tricked into entering your password because you simply don't have a password.

    • Something like special hardware tokens are much better, but there's no infrastructure for their distribution.

      I seem to recall a rather high profile [] company introduce a hardware token to assist with account security, it was greeted with much enthusiasm [] by it's customers. Yet before long, it too, failed [] . []

      • by Cyberax ( 705495 )

        So? Of course you can screw up anything.

      • by Rakishi ( 759894 )

        It didn't seem to fail except in the sense that it doesn't provide 100% from all possible methods of attack. If someone is able to get physical control of your token and learn your password then you have bigger problems to worry about.

        • It fell to a social engineering attack.. blizzard screwed up basically (should have demanded photo ID but didn't).

          Even the most secure systems can fail in that manner if the human side fails. One of the first things that's done when security is tested in an organisation is phone up, make up a story and see if the person on the other end will give up a password.

          Of course the reason the hacker had enough information to pull that off is the owner was an idiot and gave their details away - probably responded t

    • Re: (Score:3, Insightful)

      by hackstraw ( 262471 )

      Something like special hardware tokens are much better, but there's no infrastructure for their distribution.

      USB thumbdrive, passphrase protected private key.

      Once sshd can tell if a private key has a passphrase and its authorized keys can be centrally managed, then there is never a reason a user should ever type a password. Just unlock the private key locally, and you can go wherever you are already authorized to go.

      I just think its so stupid that we have to type usernames and passwords all the time. The

      • I mean this is the way credit cards work. No password whatsoever, and I can present my card, and a purchase is made, no password ever.

        Yes. Isn't it encouraging how credit cards are far less secure than my virtual server?

        I mean, I don't use a username/password to enter my $500,000 house, or to drive my $100,000 car,

        No, but you hopefully are using a key, at least. And I know some of us use combination locks -- which is, you know, entering a passcode to get into your house or car. Or office.

        If you don't use either, would you mind posting where you live?

      • Anyone who holds your credit card can charge until you report it stolen.

        Nothing stops anyone from breaking and entering your house except "law" - brick+window, or crowbar + back door, or bumpkey + front door = entry.

        Your workplace has a kind of password - the people you work with recognise you. Try walking into some random place where you don't work - even a big company where there are too many employees for everyone to recognize everyone.

        You may be able to cart off a computer with the right ploy. On the ot

    • by SanityInAnarchy ( 655584 ) <> on Sunday August 10, 2008 @03:38PM (#24548217) Journal

      I felt I had to respond to your article about passwords. It's been Slashdotted here: []

      But I felt it was important enough to write directly, and concisely, because you seem to have missed a fundamental point of OpenID.

      OpenID promotes "Single Sign-On": with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials.

      OpenID supports single-sign-on. There is nothing about it which requires you to use the same identity everywhere -- or even the same provider.

      But more importantly:

      OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else's Web site.

      Nothing about OpenID requires a password.

      I'll say that again: NOTHING about OpenID requires a password.

      What OpenID does is, in proper implementations, it allows us to sign in with any provider we choose. I could choose my own server as a provider -- thus, it's not necessarily "someone else's web site". And I don't have to use passwords -- I can use a password and a "security question", I can use public-key cryptography, or I can hire a secretary to sit at the server in question and only authorize requests when she receives a phone call from me.

      Even if we assume everyone continues to use the same password, with the same account, everywhere, it's still better than a conventional login. With the conventional login, every site I log into could steal my password and use it to login as me elsewhere. With OpenID, only my OpenID provider can do that.

      One single-point-of-failure is better than N single-point-of-failure.

      You can't use Microsoft-issued OpenID at Yahoo, nor Yahoo's at Microsoft.

      If true, that seems about on par for a technology in its infancy. Remember email? Used to be, you could only send mail to other people with the same ISP. Now, I can send mail to anyone, on any ISP, so long as I have their address.

      So that says more about Yahoo and Microsoft's understanding of the technology than it says about the technology itself.

      • Thank you.

        The level of ignorance about what OpenID is or isn't is fairly staggering even amongst technical people.

        I think the OpenID people have an uphill battle trying to educate the masses. I hope they can succeed, but I have my doubts.

        • I think a lot of the confusion is because OpenID was presented early on as an alternative to Microsoft's Passport - which is exactly what GP was rebutting.

      • Take a look at vidoop [] They present you with some pictures - you pick out the ones that fall into the catagories that you picked earlier (picture A is a space-station, Picture E is a Dog, Picture F is a car. so you can enter A, E and F in any order The letters and pictures change next time but one will still be of a space-station, one of a Dog, one of a Car.
        • They present you with some pictures - you pick out the ones that fall into the catagories that you picked earlier

          How is this relevant?

          Oh wait, I know: If Vidoop was smart, they'd become an OpenID provider. (Maybe they have already?)

          That was the point: If OpenID is widely adopted, then you can use things like Vidoop anywhere you want, so long as they support OpenID. The sites you're trying to authenticate with don't even have to know about Vidoop, much less go out of their way to implement it.

    • by Niten ( 201835 )

      Yeah, OpenID can work with just about any authentication scheme, all without requiring you to provide your credentials on someone else's site.

      A much more apt criticism of OpenID would be that it relies on DNS for authentication purposes, and DNS is fundamentally insecure. Why bother stealing passwords when you can just poison the cache of an OpenID site's nameservers, tricking the site into authenticating users against a bogus OpenID server of your choosing?

      • by Cyberax ( 705495 )

        In theory, hardware tokens can also authenticate that the OpenID server is the real one.

        • by Niten ( 201835 )

          Right, but that's not actually relevant to the type of attack I'm describing. I should have been more clear:

          Suppose Alice runs a web site at http://alice.example/ [alice.example], which uses OpenID to authenticate its users. One of her web site's users is Bob, whose OpenID URL (http://bob.example/) delegates http://charlie.example/ [charlie.example] as its OpenID authority, by using the requisite HTML tags in his web site:

          <link rel="openid.server" href="https://charlie.example/" />
          <link rel="openid.delegate" href="http://cha

          • by Cyberax ( 705495 )

            Yes, it's a weakness. We really need to speed up DNSSEC adoption.

            In fact, I'm going to install it on my DNS servers ASAP.

  • ...and we must enforce their strength and use like bastards.

    Let us not be pussies about this, short of submitting a biometric signature every time I want to authenticate just how else can a machine tell I am me?

    • Let us not be pussies about this, short of submitting a biometric signature every time I want to authenticate just how else can a machine tell I am me?

      You could implant an RDIF chip to someone heart which only functions when the heart is beating so if someone removed that it not longer function.

      A little extreme, but no one could ever call you a pussy.

      • by ettlz ( 639203 )

        You could implant an RDIF chip to someone heart [...] A little extreme, but no one could ever call you a pussy.

        No, they'd call me Harkonnen.

  • by FlyingSquidStudios ( 1031284 ) on Sunday August 10, 2008 @03:04PM (#24547895) Homepage
    But doesn't this restrict people to using secure sites only from their own machines? I have encountered situations where I was at friends' houses, relatives' houses or even a work computer where I want to do something somewhat security-sensitive like checking e-mail. Wouldn't this sort of security measure make that far more difficult?
    • But doesn't this restrict people to using secure sites only from their own machines?

      Yes, yes it does. Several commenters have suggested workarounds to this, like carrying memory sticks with all your keys and the like. But I think it's highly unlikely that will never catch on. Personally, I don't see any problem using passwords, as long as the user is smart about usage (i.e. no public terminals, use only over encrypted connections, mixed upper/lower case/numbers/special characters, keep it secret, etc.).

      But to be fair, no, I did not RTFA.

    • Yes, that's THE big problem. I've messed with it a couple of years ago. I wanted to make it work under Linux as well as Windows. But in the end it only worked partially and it wasn't really practical.

      To make this kind of thing practical you'd have to define an absolute standard for smartcard authentication.

      This probably means that there should be an USB standard that is as compatible with all smartcard vendors as "universal mass storage" is for usb storage. And all applications, ISV's and service providers

  • by ocularDeathRay ( 760450 ) on Sunday August 10, 2008 @03:06PM (#24547915) Journal
    Jean-Luc Picard: Begin auto-destruct sequence, authorization Picard-four-seven-alpha-tango.

    Beverly Crusher: Computer, Commander Beverly Crusher. Confirm auto-destruct sequence, authorization Crusher-two-two-beta-Charlie.

    Worf: Computer, Lieutenant Commander Worf. Confirm auto-destruct sequence. Authorization Worf-three-seven-gamma-echo.

    Computer: Command authorization accepted. Awaiting final code to begin auto-destruct sequence.
    • Re: (Score:2, Interesting)

      I was always under the impression that this was a two-stage security system as well. There is the password ("Picard-four-seven-alpha-tango") and a voice-print analysis to confirm it was the correct person issuing the order.

      Of course, I don't remember any time where Worf tried to use Riker's credentials, so I can't really back it up...
    • Well, it only looks tragically insecure, as is it well-known that for licensing rights reasons, TNG wasn't allowed to show the crew reading from their RSA SecurIDs. So truly, voice authenticated RSA isn't that unreasonable, is it?

      Jean-Luc Picard: Begin auto-destruct sequence, authorization Picard-four-seven-alpha-tango.

      Beverly Crusher: Computer, Commander Beverly Crusher. Confirm auto-destruct sequence, authorization Crusher-two-two-beta-Charlie.

      Worf: Computer, Lieutenant Commander Worf. Confirm auto-

      • Add to that the ship is tracking the whereabouts of each crew member at all times. So that adds a factor of "Where you are" I suppose it's done with combadges though so perhaps only a "what you have"
    • Re: (Score:3, Funny)

      by Kidbro ( 80868 )

      Sheridan: This is Captain John J. Sheridan. Serial number XO7Y39-Alpha. Security code: obsidian.
      Ivanova: This is Commander Susan Ivanova. Serial number Z48M27-Epsilon. Security code: griffin.
      Michael Garibaldi: This is Chief Warrant Officer Michael Garibaldi. Serial number V17L98. Security code: peekaboo.
      . . .
      Ivanova: Peekaboo?
      Garibaldi: Would you have guessed it?

      (linky [])

  • by sam0737 ( 648914 ) <sam@chowchi.cGINSBERGom minus poet> on Sunday August 10, 2008 @03:08PM (#24547929)

    OpenID does not required the use of password as the way for human to authentication oneself to the system.

    It's just up to the OpenID signatory to use whatever technology to authenticate someone. This human interface is decoupled with the underlying authentication.

    Although most public signatory currently use username+password, but it could be change. Say you could implement your own, using PKI to recognize your own certificate stored on removable media. If you gone crazy enough, nothing stop you from implementing One-time password + Biometric + whatever-you-can-think-of to authenticate yourself to your own signatory.

  • i have trouble keeping track of all my usernames and passwords like everyone else

    so i put it in passwords.txt in my shared emule folder, so i can access it anywhere in the world ;-)

    smart, huh?

  • What about digitags? (Score:3, Interesting)

    by nicc777 ( 614519 ) on Sunday August 10, 2008 @03:25PM (#24548097) Homepage Journal
    My bank uses a combination of Digitag [] and SMS notification as added layers of security.

    In South Africa, everyone with a bank account by law has to undergo a KYC process (know your client). This basically means that you as a client have to verify your ID at a branch (in person) with ID documents and some of your monthly bills. Your cellphone number is then captured to which all notifications of activity on your accounts are sent.

    The Digitag [] is used during online authentication. As a further backup, a one time pin (OTP) is send to your cellphone. This OTP is required for certain transactions like once off payments.

    Granted the system is not perfect (there is still human stupidity), but I would like to hear your comments on these tpye of systems, as they are becoming more and more part of our lives.

  • by master_runner ( 958234 ) on Sunday August 10, 2008 @03:40PM (#24548243) Homepage
    Although the password is still there, many OpenID providers are moving towards advanced multi-factor authentication. For example, when I (or anyone else) attempt to log in to my OpenID account, the account provider calls my cellular phone. I must answer the call and confirm (by pressing the # key) in order to log in. This means that in order for an intruder to gain access to my account, they must have my password and my mobile phone, and if anyone else tries to log in to my account the unexpected call will alert me to this fact. I also know that other OpenID providers support the hardware key popularized by PayPal that generates a one-time password for each login. Other OpenID providers (including mine) support authentication via SSL certificates. There's a whole range of alternative and multi-factor authentication schemes offered by today's OpenID providers, and over time more and more methods are being introduced. OpenID allows users to choose an authorization service based on the security that they offer rather than based on what website they want to log in to.
  • MyOpenID (Score:3, Informative)

    by lattyware ( 934246 ) <> on Sunday August 10, 2008 @03:43PM (#24548261) Homepage Journal
    MyOpenID allows you to use a phone call to log in. When you try to login, they call, you, and you press hash, it logs you in. Free too.
  • Quoth TFA:

    Instead, machines have a cryptographically encoded conversation to establish both parties' authenticity, using digital keys that we, as users, have no need to see.

    I've been doing that for years with SSH []. Funny, that.

    • by SuperQ ( 431 ) *

      All we need is for websites to accept the public key strings, and the browsers to interact with ssh-agent. It would take someone like Google to accept this type of thing for gmail for it to get any kind of acceptance.

  • There seems to be a slight misconception in the NY Times article around OpenID being tied to passwords. OpenID does not specify the authentication mechanism for the user to their OpenID Provider which means that we've seen many companies (including Microsoft) experiment with alternative authentication mechanisms atop OpenID. The big benefit OpenID then provides them is that they're instantly able to start letting users use their new authentication mechanism at any site which accepts OpenID logins. More a
  • by BPPG ( 1181851 ) <> on Sunday August 10, 2008 @04:08PM (#24548477)

    At my university, they were trying an experimental password alternative that comp-sci students could opt-in for.

    Basically, we were presented with an image; this particular image was a bunch of cars in a parking lot, with people walking or standing around. I think it was a 400 by 400 pixel image. To set your pattern, you had to click and memorize five or six arbitrary points in the image, and also memorize the order you click them in. The idea was that it was supposed to be a lot easier to remember than an equally powerful password. Some people liked the new system, while others had a lot of trouble remembering the exact position of each of their clicks. I fell into the latter group.

    • EXACT position? You'd think a 'fairly close' position would do. For people walking, car park etc, you'd probably go with a specific car or face/hand/leg rather than [327;173].

  • Solutions based on technology have a simple but critical flaw: When they break, they're broken and exploitable despite anything you could do. The human factor is not only a security risk, it can also be a security asset. Humans are far better at plausibility checking, if they have proper training, of course.

    Modern machines, no matter how resilent the technology behind them, offer inherently such a variety of possible attack vectors, that nobody can say with certainty that no attack can be performed. I would

  • E.g., Trustbearer is an OpenID provider that will leverage smartcard-based PKI keys for authentication. Best of both worlds. []

    The way this works is by something called "key continuity management" (KCM). Users of SSH RSApubkey authentication will recognize how KCM works. Everyone else should read Simson Garfinkle's "Johnny 2" paper: []

    In short, KCM works by establishing trust with a specific key, ideally by an out-of-band channel. If you establ

  • What about this:

    The server has the public keys of all the users, and encrypts (with the public key) a one-time string for a logging in user to decrypt. When the user has decrypted the string, they enter that as the password, and get access to the system.

    For users who do not have a stored key (or have an invalid key), the server would transmit a random string and not allow any entered string to work. The error message would be something like "invalid passphrase or user not known" [or just the usual "login in

Loose bits sink chips.