Ask HN: Two-factor authentication and other extended security measures
YubiKey is nice, but has an acquisition and processing cost (get hardware from Sweden, reprogram with a new private key, collect postal addresses, send out to customers, deal with customers losing keys). SMS messages can be almost universally sent, but require some third party provider or modem to send worldwide (is there a good third party service to send out a SMS message to any cell phone reliably?)
We don't store e.g. PCI (payment) data or other highly sensitive data where there are some laws requiring additional protection, but still have somewhat sensitive data. If you look at the questionnaire from http://www.sharedassessments.org/ (warning: annoying registration required) how does your security stack up? This may not be something you run into if you do B2C or B2B for small companies, but a large company may have a vendor assessment programme which will require you to go through this. That happened to me and just going through that questionnaire may leave you rather concerned.
Here are my security discussion topics -- while security occasionally comes up as a topic, I think a practical discussion might be useful:
1) What do you do for account security of your web app? There are the obvious issues: XSS, CRSF, sql injection, hashed (bcrypt or similar) passwords. Do you require SSL? Do you train users in understanding MITM attacks and not accepting invalid certificates? Require strong passwords, require password changes? Do you apply different standards to staff users (using SSH or some higher-powered web app login) vs client users?
2) Do you use two-factor authentication? Do you have an open SSH port or restrict SSH access to only certain hosts or even only terminated VPN connections? Do you allow users to restrict their logins only from certain IPs or perhaps use client-side certificates?
3) What do you do with potentially sensitive data of your web app? Disk encryption and other symmetric encryption seems to protect only against the unlikely case of hardware theft; if you're collecting some data you need to access later encryption does not seem useful.
4) How do you sell higher security to your users? Unless your audience is technically savvy or has a good IT department how do you convince them to e.g. buy a hardware token or start using SMS one-time passwords to login? They might ask "So you want me to buy this hardware token, are you saying my data is insecure now without it?"
5) Do you use any other security measures? E.g. mod_audit to try to stop some XSS attacks; tools like snort or tripwire to analyze traffic and server integrity?
6) How do you get to higher security? Following some good checklist? Hire tptacek or a similar well-reputed security company to go over your code and practices? In-house scans with Nessus?
1 comment
[ 2.1 ms ] story [ 15.5 ms ] thread1) We encrypt password using bcrypt, so in case of a database theft they are not easy to crack. We require SSL any time any authentication action is required -- cookies are sent with the secure option so over HTTPs only, and login/password must be entered over SSL. When you create an account your email gets a link that you have to follow and only there enter your password, same if you forget your password. No user will have an email sent nor can he even ask support what his password is. Of course this requires he can securely access his email account without anyone else snooping.
1b) We leave password strength up to customers and very few (1%) of them care to enable settings above basics (e.g. requiring password change every X days or password consisting of both numbers and digits and special characters). So while the feature is there technically, it's a failure socially.
1c) CSRF is handled by generating a token when generating a sensitive form; that token must be used when submitting that form. XSS is prevented by quoting of untrusted user input when displaying it.
2) Our SSH ports are wide open, but brute password cracking from a single IP is prevented by fail2ban which blocks IPs that repeatedly try to enter bad usernames/passwords. This does not protect against distributed password cracking which is why I like two-factor authentication. Many employees from roaming IPs access our SSH port so we can't easily firewall them, but I have a solution in mind where users can enable IP access via the web app (which uses different usernames/passwords).
3) Backups are encrypted, but that's it. If you collect fact X that may be sensitive, how do you protect that fact on disk if you have a rich web UI that uses that fact X for various reports?
5) We use mod_audit with some cut down rules and a few additional custom rules; an external company runs a Nessus-like scan. I've installed various toolkits to check vital binary integrity (rkhunter), have automatic updates from a good vendor (Red Hat Enterprise Linux).
6) I have started getting nightmares around about thepiratebay.org hosting a giant mycompany-complete-data-hahahahaha.set torrent, thus this posting :-)