In my never-ending quest to make the world make sense, I have turned my attention to miicard.com once again. They are pretty good, use HTTPS where it counts, don’t email my stored password around, and I even let them verify bank accounts. But they are not without some issues. In the interest of cutting to the chase, I’ve emailed James Varga (CEO) & Stuart Fraser (CTO) links to this post.
Though the https://my.miicard.com site uses HTTPS, Qualsys reports it is subject to man-in-the-middle attacks which capped it at a B rating at SSL Labs:
https://www.ssllabs.com/ssltest/analyze.html?d=my.miicard.com
Also, the password recovery system is broken. (Seems like they all are, right? Sigh…)
If requested, it changes your password immediately and then emails you the new one. An easy DOS is to just run the password reset every 10 seconds against a target users account. Since it changes the password right there and then, that user will never be able to log in until the attack ceases. It can even be farmed out as a Mechanical Turk task – 10 resets for a penny, 10 seconds apart. That makes the reset requests originate from thousands of random IP addresses and costs 36 cents an hour.
Sending the password in email isn’t cool either. OWASP suggests sending a reset link instead. Yes, it’s true that whether its a password or a link, it is still sending a unique token of some sort over email and that can be intercepted. Whether it’s a temporary password or a link, if it is intercepted it can be used to log onto the user’s account. So why care whether it’s a password or a link?
User expectations. Security hygiene.
We train users that we’ll never ask for passwords and not to give them out. The user is the only one EVER who is supposed to know the password. They create it, exchange it over a secure link, then the web site hashes it 5,000 times with salt before storing it. The web site should NEVER be able to tell the user their password.
We also train users not to click on links in emails so password recovery is going to break one of these two. Does it matter which? Yes. Consider that breaking the password rules teaches users that there are some occasions when the web site knows your password and that this is OK. This is especially bad if the reset was not initiated by the user and they see a password showing up unsolicited. The last thing we want to teach them is that the web site knows their password on occasion or that strangers can manipulate it easily and that all this is OK. On the other hand, having a reset link that is OK to click when initiated by the user and not OK to click when not initiated by the user actually reinforces correct security hygiene concerning links in emails.
Proposals:
- Configure the TLS on the miicard servers to mitigate the BEAST attack or report to Qualsys labs if they are showing a false positive.
- Fix the account recovery. I wrote about this earlier but the highlights are to send a password reset link instead of a new password, that the link quickly expires, and not to change the password until confirmed by clicking the link.
Once we make the world make sense, it’ll be a lot easier for ordinary people to make sense of the world.
Update: This post has been significantly trimmed down from the original to remove complaints about cosmetic issues and focus on the security aspects. The good folks at miicard have the complete list and are working on the issues raised, both the cosmetic and the more urgent ones.
Leave a Reply