Passport Passwords Stored in Plaintext
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2814881,00.html Your stolen Passport By Wayne Rash, Enterprise September 26, 2001 9:37 AM PT URL: The way Dave Thomas describes it, he and his staff were trying to track down a series of unusual bugs in Windows, when they stumbled across something that really worried them. There, on their screens along with the code they were debugging, was the name and password they'd just used for Microsoft's Passport service. Worse, it was in plain text, and readily accessible. As he looked more deeply, he realized that creating a worm that could recover that information would be, in his words, "trivial." Thomas, who is CTO of the Oregon-based software quality assurance company, Bugtoaster, says that he wasn't really trying to get into the security business, but that this was something too obvious to let pass. It was also too important. Microsoft's Passport service is a core piece of its .NET strategy. Anyone who uses MSN or the MSN Messenger has a Passport. As the Microsoft Internet strategy moves forward, the Passport will serve as a single sign-on for interactions with any company that requires Passport-based authentication, and Microsoft is working hard to sign up as many companies as possible. If Microsoft's plans reach fruition, users will only need to authenticate once with the Passport Data Center (run by Microsoft); then they can travel around the Internet, moving from one Passport-enabled service to another without having to log in again. This is a great convenience for users. The problem is, it's also a great convenience for hackers and thieves. All they need is your e-mail address and password to go anywhere you go because Passport requires that you use your e-mail address as your user ID; and you use a single password for all Passport-enabled sites. Worse, because Microsoft is also tying its Wallet service to the Passport, they can also spend your money and get your credit card information. The only upside (if you can call it that) to Bugtoaster's findings is that this particular security hole only applies to Windows 9x and Windows Me. Unfortunately, versions of Windows working off the NT code base are vulnerable, but for different reasons. Windows 95/ME API reveals clear text Bugtoaster's discovery is related to the Windows dial-up networking (DUN) application on the client side. An API that DUN shares with other applications retrieves the Passport credentials from an encrypted file. When a Windows 9x/ME user logs into the Passport Data Center, the API passes sign-on information in clear text from one process to another in memory where a worm could easily find the information because it's an area specified in the API for Windows. While the API often passes log-in information to other services, such as your ISP, hackers with malicious intent have had no incentive to steal this information because there was little to be gained. With Passport and the carte blanche it's designed to give its users, the stakes are completely different. Windows NT and 2000 don't have the clear text problem, but are still vulnerable Windows NT and 2000 not totally safe either One of the benefits of using a version of Windows based on the NT code base (NT, 2000, or XP) is that the API encrypts the log-in information before passing it. But that doesn't mean you're in the clear just because you're using NT or 2000. According to Steve Gibson of the highly respected security firm of Gibson Research, getting the same Passport sign-on information from those operating systems requires a different approach, but he also calls the process trivial. According to Gibson, it's a simple process to capture sign-on information from any version of Windows using a worm that can record keystrokes. Like the data that hackers could have snooped from the API, the only reason it hasn't been done in the past, he says, is that it wasn't worth the trouble. Now, however, with Passport, the target is much more attractive. While it might have been pointless to get someone's ISP password, Passport opens up broad access to any site that uses it. In a response to our questions, a Microsoft spokesperson, who requested anonymity, admitted that password information is passed in clear text within Windows 95 and ME when a user logs on to Passport or any other system. While Microsoft also recognizes that a worm, Trojan horse, or other hostile code could invade Windows and capture a user's sign-on information, the spokesman lays the blame on hostile code and not on any weaknesses in Windows 95, ME or Passport. "By design, a program running on a user's computer can in general take any action the user can," he writes in an e-mailed response. "The real issue here is hostile code, not Passport." According to him, the company doesn't plan to make any patches to the vulnerable versions of Windows to help stop such theft of Windows sign-on information. "Microsoft will not be providing a patch for this b
Re: Passport Passwords Stored in Plaintext
On Fri, Oct 05, 2001 at 01:22:31PM -0500, Joseph Ashwood wrote: > > [ Greate description of M$ ... ] > I am unaware of anything microsoft has ever written > that could be considered secure and there is evidence that they plan Outlook once offered me the choice between "no encryption" and a so called "compressible encryption". :-D Hadmut - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Passport Passwords Stored in Plaintext
- Original Message - From: "bernie" <[EMAIL PROTECTED]> > Some of the people here wants to use the .NET for critical applications. I'm sorry. > How secure is the .NET? The short answer is that it isn't secure. There are two main problems with it being secure. The first is the password vulnerability that you replied to. The second is that it uses a custom blended Kerberos-esque implementation. I say Kerberos-esque because it has some significant problems. First it uses RC4, a cipher which is increasingly being considered insecure, and in using it windows doesn't take the precautions necessary to make it secure. They are the only company foolish enough to have embedded access control information in the kerberos ticket, this adds even more leaking information, and just enough of it to determine the users password. Basicly they have made nearly every effort to eliminate the security of the system while making it appear secure to a layman. For further evidence that Microsoft can't do anything secure I point to (in no particular order) IIS, pptp, pptp2, Internet Explorer, Outlook Express, Windows 95, Windows98, WindowsME, WindowsNT, Windows2000, and while I haven't verified it yet I believe also WindowsXP. Some of these probably need some explaination, IIS is the script kiddie choice it has more holes than a pound of Swiss cheese. pptp was severely broken, pptp2 was slightly less severely broken. Internet Explorer has had so many security vulnerabilities I can't even count that high. Outlook Express is a virus writers dream. Windows95 offered no security, same with 98 and ME. WindowsNT is subject to extremely basic attacks on the password system that Microsoft refused to recognise, same with 2000, and probably the same with XP. In 2000 MS introduced a "secure" encrypted filesystem which lacked any reasonable ability to encrypt documents securely (it put the keys in a file in plaintext, the file is easily readable). Even the cryptoAPI that Microsoft designed and offered has holes in it, allowing arbitrary code to be run in the place of what the programmer intended. I am unaware of anything microsoft has ever written that could be considered secure and there is evidence that they plan to continue this less than stellar performance with .NET. Joe - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Passport Passwords Stored in Plaintext
The original proposal for dot-net was to *centralize* all of the personal information on at one location. This part may be changing with recent capitulations regarding, of all things, interoperability. This idea of centralizing everyone's personal information is the scary part of all this to me, even recognizing how permeable and abuse-ready the company's software seems to be. on another topic - Has anyone thought about how a scheme like .Net could be aided by 'reasonable and non-discriminatory (RAND)' licensing terms creeping into W3C Recommendations? Now there is a scary thought IIS (Ignorance Is Strength) On Fri, 5 Oct 2001, Joseph Ashwood wrote: > - Original Message - > From: "bernie" <[EMAIL PROTECTED]> > > > Some of the people here wants to use the .NET for critical applications. > > I'm sorry. > > > How secure is the .NET? > > The short answer is that it isn't secure. There are two main problems with > it being secure. The first is the password vulnerability that you replied > to. The second is that it uses a custom blended Kerberos-esque > implementation. I say Kerberos-esque because it has some significant > problems. First it uses RC4, a cipher which is increasingly being considered > insecure, and in using it windows doesn't take the precautions necessary to > make it secure. They are the only company foolish enough to have embedded > access control information in the kerberos ticket, this adds even more > leaking information, and just enough of it to determine the users password. > Basicly they have made nearly every effort to eliminate the security of the > system while making it appear secure to a layman. For further evidence that > Microsoft can't do anything secure I point to (in no particular order) IIS, > pptp, pptp2, Internet Explorer, Outlook Express, Windows 95, Windows98, > WindowsME, WindowsNT, Windows2000, and while I haven't verified it yet I > believe also WindowsXP. Some of these probably need some explaination, IIS > is the script kiddie choice it has more holes than a pound of Swiss cheese. > pptp was severely broken, pptp2 was slightly less severely broken. Internet > Explorer has had so many security vulnerabilities I can't even count that > high. Outlook Express is a virus writers dream. Windows95 offered no > security, same with 98 and ME. WindowsNT is subject to extremely basic > attacks on the password system that Microsoft refused to recognise, same > with 2000, and probably the same with XP. In 2000 MS introduced a "secure" > encrypted filesystem which lacked any reasonable ability to encrypt > documents securely (it put the keys in a file in plaintext, the file is > easily readable). Even the cryptoAPI that Microsoft designed and offered has > holes in it, allowing arbitrary code to be run in the place of what the > programmer intended. I am unaware of anything microsoft has ever written > that could be considered secure and there is evidence that they plan to > continue this less than stellar performance with .NET. > Joe > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RC4 [was: RE: Passport Passwords Stored in Plaintext]
[This response probably can't get to all of the lists to which the original message was addressed to. Feel free to forward it to those lists, if you can, and to other addresses as needed. -pt] > Alex Alten[SMTP:[EMAIL PROTECTED]] wrote: [.discussion of .NET weaknesses deleted]] > RC4 is broken. Period. The key setup machinery has been broken and the > internal PRNG/pad generation machinery has been partially broken. > > Just say NO to RC4. > > Alex Alten > [EMAIL PROTECTED] > - [I work for RSA, which owns RC4] I strongly suggest that Alex and other interested parties read Ron Rivest's recent paper on precisely this issue. It can be found at http://www.rsasecurity.com/rsalabs/technotes/wep.html (extract) [...] In protocols such as WEP, it is often necessary to generate different RC4 keys from different messages (or packets) from a common base key. A method frequently suggested to obtain the keys is to add or concatenate a counter to the base key. The key-scheduling algorithm of RC4 has been widely recognized to be rather lightweight for this purpose, particularly when the initial few bytes of plaintext are easily predictable. RSA Security has discouraged such key derivation methods, recommending instead that users consider strengthening the key scheduling algorithm by pre-processing the base key and any counter or initialization vector by passing them through a hash function such as MD5. Alternatively, weaknesses in the key scheduling algorithm can be prevented by discarding the first 256 output bytes of the pseudo-random generator before beginning encryption. Either or both of these techniques suffice to defeat the new attacks on WEP and WEP2. [...] (end extract) Essentially, WEP sends successive packets (with well known headers) using the initial output of RC4 keyed with successive keys. This opens WEP up to a related-key attack. I'm really curious what led to the use of RC4 in this weird mode; a block cipher in CBC mode would have been more appropriate. I suspect that the selection was made at a time when 40bit RC4 was [relatively] easy to export, while stronger block ciphers such as 56 bit DES were not. The moral re crypto restrictions is left to the reader. Peter Trei [Disclaimer: I work for RSA, but this note contains my own opinions.] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: RC4 [was: RE: Passport Passwords Stored in Plaintext]
On Thu, Oct 11, 2001 at 01:31:36AM -0700, [EMAIL PROTECTED] wrote: | On 8 Oct 2001, at 11:37, Ray Dillinger wrote: | > In which case, what you've got isn't RC4 anymore | | You do not understand encryption. | | RC4 is an encryption method, that needs to be part of a | protocol. The protocol can be designed correctly or | incorrectly, but either way it is still a protocol that uses | RC4. | | In the usual protocols that contain RC4, each session has a | new transient session key. The fact that RC4 leaks a small | amount of information about that session key is unimportant | in such protocols. | | RC4 is like a brick that can be used to build a house. I'd say that RC4 is like one of those cool, semi-opaque glass bricks. Not in the sense that it is weak (you can put quite a bit of load on a wall of those) but in the sense that it is different than your typical dried-mud sort of brick. Designing protocols is a hard field, and there seem to be lots of mistakes made when people use RC4. Is that because its a bad cipher? No, its because people aren't used to working with it. Because of that, I tend to look askew at RC4 based systems. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: RC4 [was: RE: Passport Passwords Stored in Plaintext]
On Sun, Oct 21, 2001 at 04:11:19PM -0700, Jeff Simmons wrote:
| On Sunday 21 October 2001 02:52 pm, you wrote:
|
| >Designing protocols is a hard field, and
| >there seem to be lots of mistakes made when people use RC4. Is that
| >because its a bad cipher? No, its because people aren't used to
| >working with it. Because of that, I tend to look askew at RC4 based
| >systems.
|
| Are you referring to RC4 in particular, or streaming cyphers in
| general? And if it's just RC4, do you have a streaming cypher that
| you prefer to it?
Good question; the problems with RC4 have been a mix of not knowing
how to use stream ciphers ("Don't cross the streams!") and issues with
RC4 (needing to discard the first little chunk of stream as it gets up
to speed.
I've seen people go to RC4 for speed more than for its stream cipher
nature. I tend to push towards block ciphers, simply because we in
the public world have a lot more experience using them.
Adam
--
"It is seldom that liberty of any kind is lost all at once."
-Hume
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: RC4 [was: RE: Passport Passwords Stored in Plaintext]
Adam Shostack wrote: >| RC4 is like a brick that can be used to build a house. > >I'd say that RC4 is like one of those cool, semi-opaque glass bricks. > Considering that RSA Security changed their logo to a red 'brick' a while back (they called it a brick as part of the corporate PR around the change). I can't help but see the irony of using this analogy to describe that which they claim is a trade secret but is widely known :-). eric - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: RC4 [was: RE: Passport Passwords Stored in Plaintext]
At 10:04 AM -0400 10/22/2001, Adam Shostack wrote:
>On Sun, Oct 21, 2001 at 04:11:19PM -0700, Jeff Simmons wrote:
>| On Sunday 21 October 2001 02:52 pm, you wrote:
>|
>| >Designing protocols is a hard field, and
>| >there seem to be lots of mistakes made when people use RC4. Is that
>| >because its a bad cipher? No, its because people aren't used to
>| >working with it. Because of that, I tend to look askew at RC4 based
>| >systems.
>|
>| Are you referring to RC4 in particular, or streaming cyphers in
>| general? And if it's just RC4, do you have a streaming cypher that
>| you prefer to it?
>
>Good question; the problems with RC4 have been a mix of not knowing
>how to use stream ciphers ("Don't cross the streams!") and issues with
>RC4 (needing to discard the first little chunk of stream as it gets up
>to speed.
>
>I've seen people go to RC4 for speed more than for its stream cipher
>nature. I tend to push towards block ciphers, simply because we in
>the public world have a lot more experience using them.
>
>Adam
>
>
>--
>"It is seldom that liberty of any kind is lost all at once."
> -Hume
>
An important advantage of RC4 is that it is easy to reproduce from
memory. If efforts to suppress cryptography ever intensify enough, it
may be the only cipher that is widely available.
There was a news report on NPR this morning that the U.S. Nuclear
Regulatory Commission http://www.nrc.gov/ has taken down its Web site
after a request by the Department of Defense to remove material that
might be helpful to terrorists. The site now says:
"In support of our mission to protect public health and safety, the
NRC is performing a review of all material on our site. In the
interim, only select content will be available. We appreciate your
patience and understanding during these difficult times."
The same could happen at NIST some day. Your tag line is
particularly apt here.
Arnold Reinhold
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
