The improbably named Moxie Marlinspike, mastermind of the CloudCracker service, strongly suggests that PPTP really isn't secure anymore.
Have a read of his blog entry which explains in great detail why that is the case.
The short version:
1) All users and providers of PPTP VPN solutions should immediately start migrating to a different VPN protocol. PPTP traffic should be considered unencrypted.
2) Enterprises who are depending on the mutual authentication properties of MS-CHAPv2 for connection to their WPA2 Radius servers should immediately start migrating to something else.
In many cases, larger enterprises have opted to use IPSEC-PSK over PPTP. While PPTP is now clearly broken, ISEC-PSK is arguably worse than PPTP ever was for a dictionary-based attack vector. PPTP at least requires an attacker to obtain an active network capture in order to employ an offline dictionary attack, while IPSEC-PSK VPNs in aggressive mode will actually hand out hashes to any connecting attacker.
In terms of currently available solutions, deploying something securely requires some type of certificate validation. This leaves either an OpenVPN configuration, or IPSEC in certificate rather than PSK mode.
Update Unfortunately, Rob Isaac hated this blog post, so I'm stealing these lines from Wikipedia to make him happy again.
A specification for PPTP was published as RFC 2637 and was developed by a vendor consortium formed by Microsoft, Ascend Communications (today part of Alcatel-Lucent), 3Com, and others. PPTP has not been proposed nor ratified as a standard by the IETF.
A PPTP tunnel is instantiated by communication to the peer on TCP port 1723. This TCP connection is then used to initiate and manage a second GREtunnel to the same peer.
The PPTP GRE packet format is non standard, including an additional acknowledgement field replacing the typical routingfield in the GRE header. However, like in a normal GRE connection, those modified GRE packets are directly encapsulated into IP packets, and seen as IP protocol number 47.
The GRE tunnel is used to carry encapsulated PPP packets, allowing the tunnelling of any protocols that can be carried within PPP, including IP, NetBEUI and IPX.
In the Microsoft implementation, the tunneled PPP traffic can be authenticated with PAP, CHAP, Microsoft CHAP V1/V2 or EAP-TLS. The PPP payload is encrypted using Microsoft Point-to-Point Encryption (MPPE) when using MSCHAPv1/v2 or EAP-TLS. MPPE is described by RFC 3078.
Other related posts:
Conficker wreaks havoc
A very non-obvious Firefox security hole plugged
Symantec antivirus makes encrypted files inaccessible on Vista
comments powered by Disqus