ppierald

I hope this is a troll and if it is not, you should read through your contract, look for a breach clause, and exercise that clause. Otherwise, you should eat the cost of getting a new security auditor. A good relationship with a qualified auditor can be really beneficial to your organization. If you don't have that, you are not getting any value out of the dollars spent.

Always happy to see new input sanitization libraries, but most don't deal with the especially difficult problem of safe subsets of HTML. i.e. How to accept html from an untrusted source, apply whitelisted tag/attribute combinations, and ensure safe output.

It's not Hedy. It's Hedley!

gperf - https://www.gnu.org/software/gperf/ This is a "perfect" application of a "perfect hash" generator.

UTF-8 wins for the internet because most of the payload of an HTTP request/response is 7-bit ascii characters, so it is the most efficient even in languages where UTF-16 may be more efficient because of the complexity of their character set.

I nominate you for HN Comment of the Year!

You are really protecting against local, non-root access to your box, especially when that user is the nginx child process. This can manifest itself in a number of ways, but most roads lead back to improper input sanitization and/or using user input in shell command execution.

Using the Unix file permissions to our advantage and the properties of fork'd child processes, you can scope your risk to a highly skilled adversary rather than the common adversary.

Note that not only is your SSL certificate at risk, but every file the web-server needs to read including configuration files containing passwords, API keys, and crypto keys.

The threats to passwords are generally two-fold: 1) SQLi leaking the contents of your database to the public. 2) Malicious insiders with access.

Blocking SQLi should be every web developer's first priority, not debating the efficacy of password hash algorithms, salting, and so forth.

Preventing malicious insiders is more complicated and requires other defenses besides the underlying choice of password algorithm.

scrypt, bcrypt, pbdkf are all fine in preventing the ill effects of #1 as it pertains to passwords, but prevent #1 at all costs nonetheless. Not only are your password hashes at risk, but your entire serving infrastructure and everything you consider sacred behind your firewall. Game over.

Yes. https://www.duosecurity.com/sla

Nope. Sorry if it came across that way. I am just a happy customer that loves their product. Others have mentioned Duo on this thread (and other HN threads too...) Great product, great support, reasonable price.

I would highly recommend using DuoSecurity for all your 2-Factor Authentication needs. Their solution is very slick, easy to use, and intuitive. Duo has options for every conceivable situation a user might get themselves into including Push Notifications, SMS codes, saved bypass codes via SMS, static bypass codes, phone calls, and hardware keys including YubiKey support. Additionally, they have APIs that expose any of the data/functionality you wish and native language support including Python. You can drop in their plugin to protect WordPress with a couple clicks, add support to your internal applications via Duo Web, protect your Splunk install, SSH connections, SSL VPN, and a ton of other possibilities. Also, they have a freemium model where your first 10 accounts are always free.

The GPGTools team had a paid version (beta) out for months. I felt the functionality was worth the minor investment and also ensured that there was some path forward for future revs.

The concept of putting <script src=> on my login page skeevs me out more than a little bit. This is a major security hole that won't be patched until there is native support in the browser.

Knowing that all user-data is required to have a user-credential, use this fact when issuing the urls to the browser that instantiate this request, make these urls specific to the user and cryptographically bound to their authenticated state.

session_id = '5f5513f8822fdbe5145af33b64d8d970dcf95c6e' ajax_endpoint_secret = 'this is a super secret!'

token = hmac.new( ajax_endpoint_secret, session_id, hashlib.sha1 ).hexdigest()

- or -

token = '3815c118a9e3e663215adba5e0ca626e8bdd5125'

then when your server emits the html page, your AJAX link looks like: https://example.com/ajax_api/3815c118a9e3e663215adba5e0ca626...

Here, we have cryptographically bound the AJAX url to the user's cookies, so the <script> trick won't work any longer as they don't have access to the token.

Second, you can have your server endpoint checking for the 'X-Requested-With: XmlHttpRequest' if you anticipate this to only be accessed via XHR. This is a pretty effective thwart of the <script> attack as well.

Lastly, ensure that your JSON response always is wrapped in curly braces {}. Never respond with [] From my experiments, all browsers interpret this as a code block and breaks processing when <script src=> runs.

I would recommend against using sudo su -, esp if you have <user> ALL=(ALL) NOPASSWD: ALL or such constructs in your /etc/sudoers file that exempt password requirements from executing sudo commands.

1. su gives you a root shell. Principle of least privilege dictates you should executes the fewest commands as root as required, not all commands as root because you need one.

2. sudo su - loses auditability of who executed what/when. All we know is that someone got a sudo shell at some point. When the forensics guys come along post-breach, you won't have a lot of good info to give them.

3. Loss of a shell (via command injection on a web form) may allow remote Command-and-Control of your machine.

If you need a cron or other headless process (daemons, etc.) then use NOPASSWD in conjunction with a whitelisted set of commands (not /bin/bash) to be executed.

If you need an operator to execute a command as a specific user, then use sudo -u <user> <cmd>. Even if you allow ALL commands, at least your audit logs will know what/when the command was executed.

With all powerful commands comes the responsibility of understanding how to use them safely and what the possible repercussions are.

A little heads up to the Yahoo Security team probably would have been appreciated!

I have to note that the length and strength of your AES key is no different than the complexity of your password. Once either is compromised, then you are totally exposed. So your attacker will take the path of least resistance. He can either brute-force the key or he can just break into your server and steal your config file or his you over the head with the proverbial $5 wrench.

No Terms of Service or Privacy Policy. I can imagine having a list of email addresses with people interested in getting coding interviews could be interesting to the right people with enough money.

"corporate standards" are at least partially good. They should be reasonable though and adaptive to the times. Having a set of acceptable programming languages, frameworks, etc. ensures that the company understands the risks of those choices, can apply reasonable upgrade/maintenance/security patches as needed, can attract and retain personnel that understand the language, etc. Allowing arbitrary choice leads to complete anarchy. The opposite is also at least as bad. Having one rigid language/framework leads to obsolescence and inflexibility. A good programmer will be able to make a strong case as to why this new language/platform is vastly superior to the current one because changing to the new one and supporting the old one are not zero-cost propositions.