[JDEV] MSNP8 Security Enhancement

[harmeet_im at kodemuse.com]

From: Andrew Sayers <andrew-list-jabber-jdev at ccl.bham.ac.uk>

> 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 <thoutbeckers at splendo.com>
Sent: Sep 12, 3:28 AM

> harmeet_im at kodemuse.com 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