From: Andrew Sayers <[EMAIL PROTECTED]> > True for both MD5 and SSL. However, sniffing an MD5 authentication is > trivial, and brute-forcing your password from that won't take long.
A secure hash uniquely identifies a plain text(password) but has the property that it is computationally unfeasible to get the plaintext from hash. MD5 is not the best but the one-way property is pretty sound. > If you're talking about DNS spoofing individual clients, you can already > do that with MSNP7. True, the protocol is plaintext so always limited security there, unless one encrypts the traffic. However in MSNP7 the client knows the password and never transmits that(secure or unsecure). ----- Original Message ----- From: Tijl Houtbeckers <[EMAIL PROTECTED]> Sent: Sep 12, 3:28 AM > [EMAIL PROTECTED] wrote on 12-9-2003 2:45:03: > > > >Pre MSN P8 authentication was based on client computing a secure hash > >and sending it to the server, but the new SSL authentication requires > >you to send the password over SSL. ie. the Password is actually sent > >to one of n servers. This appears (to me) to actually reduce security. > > > >- Password is sent to remote location. > > That remote location is aware of your password anyway. True, but I never sent my password to MSN in MSNP7, just a secure token derived from my password. It is also possible to store the password information without needing to store the password. > > >- If password is relayed from destination SSL server to one or more > > upstream servers, my password(not obfuscated hash) is sent to more > > nodes. > > It's reasonable to assume that the risk of someone intercepting > the > traffic between the desination server and the actual server that > verifies your password is basically the same as one of those machines > being compromised. I'm sure security for these servers and any traffic > inbetween them is *very* tight. It is a lot easier to intercept than compromise a machine. Imagine if your ISP is compromised, then may hundered or thousand subscribers are prone. The small local ISP here(Canada) has for some reason no firewall hardware. One security principal that may apply is - 'need to know'. So, does MS really need to know my password to verify me. Can't it for instance do with a fixed transformation of the password ? Of course it can. A SHA like transformation of password is the same as password as far as identification is concerned but has the sweet property that one cannot get the original from it. > > >- SSL is prone to man in the middle attack. So one can insert an SSL > > Server that appears to be the destination. This can be done if the > > DNS is compromised. (This could be done at network level, hosts file > > etc.) SSL on client side may verify destination servers identity > > against a truststore but that is vulnerable too. :-( If the SSL > > Server can be mimicked basically the attacker can create a proxy, > > appear like the real destination and slurp all passwords. My point > > is that MS has actually reduced security by forcing people to send > > their password over network instead of hash of password. > > Er.. this is new to me?! Aren't SSL certificates meant to prevent > exactly what you are describing here? Certificates are only used to identify. Server side may not even ask for it(as with MSNP8 and most HTTPS Servers) or the client may decide to either trust a configurable set or ignore the server certificates. > the only > thing you could do is relay the SSL encrypted data to where it's > supposed to go (the hotmail / passport SSL servers). There is no way to > decrypt it. If you are the SSL Server to one side and you are the SSL Client to another side, you have access to data. This is weakness in the SSL protocol, that derives directly from it being an application protocol over TCP/IP. The main trick for SSL man in the middle attack is to make client think you are a valid server, and server think you are a valid client. MSN P8 currently does not do mutual authentication, so for it any SSL client is valid and the client trusts (a) a large set of identities and (b) a truststore on client machine that can be altered. > However, with SSL there is one more advantage for Microsoft. With the > old protocol there is no way of establishing what the client is. Just > that it's someone who knows the username and password. With SSL however > there is the possibilities of client-side certificates. Yes, but PKI is hard to enforce. That is one reason we are not using SMIME. Client side certificates are expensive and easy to grab. > If Microsoft > decides to only allow their own clients and 3rd party clients with a > proper license they can choose to only provide a clientside certificate > for those clients. > > Sure, you eaily "rip out" the clientside cert. from an official MSN > client and use it in your own unofficial client or transport. Agreed, the real issue is how will they secure the client side certificate if they ever get to it. MSN official client has to be on my machine for me to use it and if it is on my machine, I can grab it and use it. > Technically it will work, but legally you're on a lot more shaky ground > than when you were simply reverse enigneering a protocol and building > your own implementation of it. In other words, one could argue that you > steal the SSL certificate and you use it to break into Microsofts > servers. I don't think so but I am no lawyer. To me if something(certificate or license or passport) identifies me, it gives me the right to use it to identify me. Putting it another way, I could permit my identification but should not require permission to use my indentification. I think, all MS is trying to do is arm twist companies like Trillian to payup, and hopefully they will not target open source products or end users. I maybe wrong, but would be really interested in reading an authoritative account on MSN P8 Security improvement. Harmeet _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
