Time Passes, Security Changes… Christian Huitema Monday, August 1, 2005 IETF, Application Area Meeting
It takes less than 1 μs to compute an MD5 checksum on this presenter’s laptop
Dictionary attacks How many guesses before the observer can crack the challenge? –1,000,000 ? –10,000,000? Do you trust users to generate “good enough” passwords? ClientServer challenge Response = name + hash (challenge, password) Observer Dictionary +
A “zombie” PC is rumored to rent for $0.10 per week on the underground market
How much does a crack cost? bitsCost simple password24< $0.00 strong password32< $0.01 pass phrase40< $ random characters47< $ random characters54< $5, bits random64> $3,000,000
Are passwords obsolete? Basic rules: –If it is generated by the user, it can certainly be cracked –If it can be remembered by the user, it can probably be cracked Exception: –If the password is exchanged over a protected connection (SSL, TLS, IPSEC) –If the challenge/response mechanism is designed to resist dictionary attacks
The average user will happily connect to a “free Internet” hotspot
Man in the middle attacks Intercept DNS requests Insert a proxy Listen to the data –Names, –Addresses, –Passwords, –Challenges Hijack connections SPAM, Ads, Buffer overflows Client AP Mock DNS Server Proxy
The practice of “hiding the SSID” facilitates the “evil twin” attack against Wi-Fi
The “evil twin” attack “Rogue” APClient Beacon: No Name Probe: example.net ? Answer: yes indeed ! Let’s get connected For user convenience, systems try to automatically connect to the “hidden home network”
Evil twin reaps interesting rewards Exploit automatic connection –Upon a connectivity indication, many systems will automatically “fetch mail”, “empty the outbox”, “synchronize”… Automatic “man in the middle” attack –Register names, passwords –Store challenge for off-line crack Quick and silent –Disconnect after a few seconds –Hardly any notification to the user
Times have changed, old security practices must be revised
Recommendations Don’t rely on challenge-response –Hardly better than clear-text password! Identify the server –Prevent man-in-the-middle attacks –Beware of PKI tricks! Encrypt the session –Protect the identity exchange –Prevent session hijacking Use secure framework –IPSEC, SSL, secure RPC, Web Services…