I'll be nice and not name you in this blog post quite yet, as I want to give you a chance of fixing things ASAP. I just hope & believe you'll listen, at least after the presentation from your company I listened to not long ago.
However I feel obligated to speak up against some of the claims you made in your presentation, as well as what I see from your demo website. Let's get started.
SMS Interception
I am sorry, but your claim that "only mobile carriers and the government can intercept SMS messages, and only centrally" really isn't true. Now I won't go into the details on how SMS messages actually can be intercepted, lets just say it is quite a bit easier then you seem to believe. As your primary solution depends on the use of "flash SMS" as you call it, you should at least reconsider whatever you presently tell your customers.
Google:"how to hack"
Googling "how to hack" is NOT an indicator of how easy or hard it is to hack anything, nor is it an indicator of how much or little "cybercrime" there is in the world. IMHO its a ridiculous demo made by sales representatives that should never be made in front of anyone. EVER.
PIN = PASSWORD
Never think of a PIN as anything else than a very bad password. Any claim that passwords are not enough, and replacing them with PINs is .... ridiculous. Easy to bruteforce, easy to predict if created by the user, even easier to guess if we know some basic info about the user.
Sending username + PIN (=password) first
I argued that in some scenarios sending a username and OTP first, then password if OTP is correct could be a good way of not exposing the password to any MITM. You argued against me, claiming that you wouldn't be able to set up a binding between your session initiation from your device and the 30-second life SMS generated and sent to me from your server. Although I'm not a programmer at all, I'm pretty sure you are WAY OFF. But don't take my word for it, look at what we do with BankID in Norway; username -> OTP -> password -> you're in.
Your homepage + partner site (same server)
No default SSL.
SSL available, but missing .com / www..com. in cert name. Result is browsers warns against using the site.
No EV-SSL. (I would recommend that for a security authentication company.)
SHA-1 signed cert, expires February 2017.
SSLv2 is supported, which is insecure, period.
SSLv3 is supported, but not vulnerable to POODLE.
No TLSv1.1 or TLSv1.2 support.
No Forward Secrecy support at all.
No HSTS headers.
No PCI compliance (although irrelevant for your site, but an indicator of bad security).
SSLLabs grade F.
SSL at your demo site
No default SSL.
SSL available (Good!)
SHA-1 signed cert, expires Apr, 2018.
SSLv2 is supported, which is insecure, period.
SSLv3 is supported, but not vulnerable to POODLE.
No TLSv1.1 or TLSv1.2 support.
No Forward Secrecy support at all.
No HSTS headers.
No PCI compliance (although irrelevant for your site, but an indicator of bad security).
SSLLabs grade F.
Your demo registration process
User account registration over plaintext http.
You send me a plaintext mail (no RFC3207 STARTTLS support) using an external mailing partner with:
- username (my email address)
- password (6 character predictable pattern; 2 letters from my name + 4 digits)
The password is permanent; no need or recommendation to change it.
Login & cookies at your demo site
I logon with username + password from plaintext email, and receive a 6-letter password by standard SMS (not "flash SMS"). Everything entered using an insecure HTTP connection. After logon I take a look at the cookies you've set on my computer. HostOnly, Session and HttpOnly. No sign of cookies marked Secure. You need to read up on session hijacking for sure.
Privacy & cookies
No privacy policy or cookie policy available on your main, partner or demo website, as recommended (required?) in the EU and your country, as part of EU. In fact the words PRIVACY or COOKIE are not mentioned anywhere on your site.
SUMMARY
Well, I believe the above speaks for itself, right? Now go to work, shooting the messenger is never a good strategy, either at conferences or out on the public Internet.
Oh, and excuse me for not registering at your partner site and check your security settings there. So far security doesn't look acceptable for me to even consider registering.
No comments:
Post a Comment
All comments will be moderated, primarily for spam. You are welcome to disagree with my posts of course.