Microsoft doesn't want passwords for Longhorn

[mc0282]

http://news.softpedia.com/news/Microsoft-doesn-t-want-passwords-for-Longhorn.shtml

the news bit old..
15 March 2005

i search the forum to see was posted already but not thing showed up..

so if there is such news accept my apologies.


" Microsoft's Trustworthy Computing"

just those 3 words gives me chills...

[Orethrius]

The authentication device is dependant on two factors, the user having to provide two authentication elements: the token and the PIN.

Define the difference between a "trusted device"/token and a password/PIN.  I defy you to tell me a PIN is not a password, and vice-versa.  If they TRULY mean they're dumping passwords in favor of alternate authetication, then I can't help but see a whole new world of insecurity, as people start using fingerprint scanners (subject to rather simple bypasses with Jell-O, a drinking glass, and a confectioner's oven) and makeshift USB dongles (rather trivial to copy to an image these days) to "secure" their systems.  Removing passwords is not just a BAD idea, it's completely ignorant of sophisticated (and even MacGuyver-esque) bypass methods.  On second thought, let's let Microsoft do this, and continue securing our systems with third-party utilities.  

[Calum]

i saw an ibm thinkpad advert the other day where the laptop has a built in thumbprint scanner, their spin of course was not having to remember your password anymore.

[mc0282]

i saw an ibm thinkpad advert the other day where the laptop has a built in thumbprint scanner, their spin of course was not having to remember your password anymore.

interesting... how about if you want to sell your laptop ?

[muzzy]

Passwords suck, and it's good to get rid of them. However, don't be fooled to think that you wouldn't have to remember anything anymore.

The two-factor authentication is more secure than plain password, because you need to have a physical device to authenticate. The idea is that you need to have something, and you need to know something. The smart card is this something you have, and the pin/password is something you know. The password, however, would not be system specific, but rather specific to the card. This way you only have to remember one password, yet the system you authenticate against won't see your PIN, only the immediate system where you're typing it will see it.

So, you wouldn't want to type it on public terminals, eh? Perhaps not, perhaps you would. While the hardware could be bugged or hidden cameras installed, TCPA should make it pretty tough to trojanize these systems in a fashion that would let anything in the system see the PIN except the security system that's responsible for it. At least, as long as users are educated to not type their PIN everywhere where it's asked. Evil backdoor apps could still try to spoof the authentic looking PIN query form, but there are ways to solve this, such as having a statusline at bottom of the screen always visible which tells if you're in secure IO mode or not.

Moving to a two-factor authentication scheme won't solve all the problems regarding authentication, but it's a damn good thing anyway, and a step to right direction. You can be sure linux and other *nix systems will follow once microsoft shows how to do it

[Orethrius]

Passwords suck, and it's good to get rid of them. However, don't be fooled to think that you wouldn't have to remember anything anymore.

The two-factor authentication is more secure than plain password, because you need to have a physical device to authenticate. The idea is that you need to have something, and you need to know something. The smart card is this something you have, and the pin/password is something you know. The password, however, would not be system specific, but rather specific to the card. This way you only have to remember one password, yet the system you authenticate against won't see your PIN, only the immediate system where you're typing it will see it.

Now I *KNOW* you're nuts.  You're honestly going to pull in favor of a dongle?  You realise how easy it is to image those, RIGHT?

So, you wouldn't want to type it on public terminals, eh? Perhaps not, perhaps you would.

No, I'd NEVER want to put a dongle anywhere NEAR a public terminal, because I cannot verify that the backend is secure.  To be honest, I'm none too wild about ATMs either, mostly because of skimmers (that's right, why don't you try implying THOSE are crackpot theories?)

While the hardware could be bugged or hidden cameras installed, TCPA should make it pretty tough to trojanize these systems in a fashion that would let anything in the system see the PIN except the security system that's responsible for it.

...or I could just duplicate your device on my password-noncompliant reader at home, and take the forgery to the bank and withdraw your entire account.  For that matter, I could mount a skimmer at your workstation (it's been done before) and log/dupe everything you do.  This wouldn't be hard, unless we're using a home user concept.

At least, as long as users are educated to not type their PIN everywhere where it's asked.

Ah, so it's the end-user-software-coder-app-protocol's fault, not the administrator's for not allowing such compromise in the first place.  I've heard this excuse someplace before.

Evil backdoor apps could still try to spoof the authentic looking PIN query form, but there are ways to solve this, such as having a statusline at bottom of the screen always visible which tells if you're in secure IO mode or not.

...which is equally spoofable, especially if you're using the cookie jar of exploits that IS Internet Explorer.  If you have two eyes, you can be complicit in spoofing a visual feedback system.  Not that it's HARD...

Moving to a two-factor authentication scheme won't solve all the problems regarding authentication, but it's a damn good thing anyway, and a step to right direction. You can be sure linux and other *nix systems will follow once microsoft shows how to do it

The problem is that we're not moving to a two-factor system.  We're moving to a device-specific system, which is about as stupid as it gets.  Let's put it this way: a bank system can be secured.  Access to the front or back can be monitored 24/7.  Reprogramming and stocking can be based on multiple-factor security.  But when it comes to the user, one device stands between them and the bank.  Now when it comes to systems like my home computers, I don't really give a rat's ass about security.  If I did, I'd be running a dongle, biometrics, and a password at boot-time - three barriers to entry.  That's right.  THREE.  The dongle can be stolen easily enough, but when it comes down to it, it's the PASSWORD that secures the system.

But then, perhaps I just fail to see the reason why I should entrust my most valued secrets to a disk that can be completely copied in a heartbeat.

[muzzy]

The article spoke of smart cards. No, I wasn't aware that they were easy to image. I know it's possible, but it's definitely tough. Currently the attacks against those tend to be timing attacks and power requirement analysis and other similar things. Non-compliant reader wont be able to duplicate the card because it won't be a dummy storage token. What comes to ATMs, the cards can be cloned because they tend to be dummy storage tokens.

Your attack descriptions assume that cards can be easily cloned, and I agree that if they can, then there are going to be issues. The point with smartcards is that they can contain some PKI mechanism, and implement it inside the card. No cloning of private key.

Also, you totally missed my point with statusbar and secure IO mode, because by design it would not be spoofable. If only the security system is allowed to draw in the statusbar area, that area can then be trusted. Well, as long as the system itself is trusted. For public internet (untrusted data) terminals, it doesn't matter one bit if the system is properly administrated if users type their PIN to every damn place that asks it.

Anyway, the problem with passwords is that it's tough to remember them. I can remember passwords to the ~20 of the systems I commonly use, but I know that most people can't do it. I also tend to easily forget passwords for systems I rarely use and reusing passwords for multiple places just sucks. Autologin (stored cookies for websites) is used on most places, because people just don't want to remember those damn passwords.

[Orethrius]

The article spoke of smart cards. No, I wasn't aware that they were easy to image. I know it's possible, but it's definitely tough. Currently the attacks against those tend to be timing attacks and power requirement analysis and other similar things. Non-compliant reader wont be able to duplicate the card because it won't be a dummy storage token. What comes to ATMs, the cards can be cloned because they tend to be dummy storage tokens.

I understand perfectly well what you mean.  The problem is that the article - and now you, for that matter - are advocating a failed technology as a security solution.  At least self-selects are variables, not constants.

Your attack descriptions assume that cards can be easily cloned, and I agree that if they can, then there are going to be issues. The point with smartcards is that they can contain some PKI mechanism, and implement it inside the card. No cloning of private key.

Indeed, perhaps I am confusing datastripes with PKIs, but my original point remains valid.  Don't be so quick to set aside the concept that swipecards were supposed to be Public Keys in the first place.

Also, you totally missed my point with statusbar and secure IO mode, because by design it would not be spoofable. If only the security system is allowed to draw in the statusbar area, that area can then be trusted. Well, as long as the system itself is trusted.

I'm glad you made that last observation, it salvaged your credibility in my book.    Indeed, what good is the security if the system cannot be trusted?  This brings out the kettle of fish that is the TCPA standard.  It's a sham, like voting booth certifications - but I digress.  "It's secure because we say it is" just doesn't carry a lot of weight with me, sorry.

For public internet (untrusted data) terminals, it doesn't matter one bit if the system is properly administrated if users type their PIN to every damn place that asks it.

Ah, but herein lies the problem.  Shopping malls are not going to take the time to secure their ATMs with the appropriate banks and agencies, it's already been proven that those are about the most INSECURE machines you can use.  But is this not supposed to be a TRUSTED system?  What good is this to stave off someone with a $300 microcam and a $100 skimmer?  You see the problem emerge as the organised rings evolve.  We need a variable solution,  not a constant device.

Anyway, the problem with passwords is that it's tough to remember them. I can remember passwords to the ~20 of the systems I commonly use, but I know that most people can't do it. I also tend to easily forget passwords for systems I rarely use and reusing passwords for multiple places just sucks. Autologin (stored cookies for websites) is used on most places, because people just don't want to remember those damn passwords.

Really, tough nookies.  If you're using the same password in more than one location, you deserve every breach you get and you know it.  At least with cookies, the password is still being used with little chance of interception outside of an MiM (and I think I'd know if someone was doing that on one of my two systems, wouldn't you?  Oh right - my shared box's kernel doesn't let me check for insecure code that could've been added by a nasty like Downloader.Ject.)  I use a couple passwords for low-priority sites (message boards and junk email, I don't really care WHO reads it), one for each site I administer, one for my bank account, one for PayPal, and a different 20-digit for every box I administer.  If you can't be disturbed to keep a bead on your private codes, you really can't expect either security or convenience.  Then again, those who would give up freedom for a little temporary security deserve neither, or so the saying goes.

[muzzy]

Self-selects tend to have a relatively low amount of randomness to them, for most cases anyway. What comes to "constants", if the private key gets stolen or cracked there ought to be a central database for public keys. Then, this database could be used to invalidate the insecure keypair and establish a new one for the given identity. This should take care of a lot of the issues associated with "constant" keys in tokens.

Assuming the cards are non-trivial to clone (PKI, as smartcards should be), the attacks at public terminals could only obtain the PIN and some cryptographic data suitable for cracking. With a proper cipher, it should still take years to get cracked, so the most viable attack is to steal the token once you've seen the password. Good luck thinking of a scheme where such attack isn't possible. And don't tell me users could memorize one-time passwords

[Orethrius]

Self-selects tend to have a relatively low amount of randomness to them, for most cases anyway. What comes to "constants", if the private key gets stolen or cracked there ought to be a central database for public keys. Then, this database could be used to invalidate the insecure keypair and establish a new one for the given identity. This should take care of a lot of the issues associated with "constant" keys in tokens.

This is precisely my point, though.  Any database worth compromising will be.  If I were to have my information protected by a bank that only used dongles, I'd switch banks immediately (if I stayed with them at all).  I'd rather have my money guarded by a swipe, a PIN, and whatever access measures they deem necessary than just a next-gen swipecard.  For future reference, all three major credit bureaus have been (repeatedly!) compromised, and a phone call to the right number with the right phrase at the right time - with a full name - could get you some very interesting information, if you catch my drift.    Nice dodge, by the way.

Assuming the cards are non-trivial to clone (PKI, as smartcards should be), the attacks at public terminals could only obtain the PIN and some cryptographic data suitable for cracking. With a proper cipher, it should still take years to get cracked, so the most viable attack is to steal the token once you've seen the password. Good luck thinking of a scheme where such attack isn't possible. And don't tell me users could memorize one-time passwords

This is the problem, though.  Don't tell me criminals are stupid, they managed to come up with skimmers to duplicate swipecards, they've come up with ways to duplicate "smart" cards too.  Technically, it's just a matter of synching the clocks and encryption streams, but I suspect it's more involved in practice.  At any rate, if someone swipes your card, you're shit out of luck.  Until a new one is issued with the information in that "secure" database, that is.  :cool:

[muzzy]

Uh, the idea of invalidate-database would be that it's not secret data. It'd just contain information which keys have been revoked. You could basically have two attacks against such database: Add key, or remove key. If you've managed to clone a card, and you can then remove the revocation status of it, then you could authenticate as the user. However, merely compromising the database wouldn't alone be effective, and with keys naturally expiring at some point, you couldn't just collect keys for a few years and then pull a big stunt. The less serious attack of adding key into the database would just make someone unable to authenticate.

What comes to smart criminals, yeah, I know. There are many attacks even against smart cards, but they tend to require quite a bit of sophistication and you can't just ask the card to give its information to you. The swipe cards can be completely read since you can touch the media directly, but with smart card you have to ask the card for the data. They're designed to never release private key and only answer challenge-responses against it, which cannot be used to determine the private key itself, only authenticate that that it's indeed the pair for the expected public key.