If you’re designing a service that requires passwords for authentication, store them using the Argon2 or bcrypt password hashing functions. Don’t use MD5, SHA-1, SHA-2 or SHA-3 — they’re not designed to keep passwords secure against attackers that gain access to your password database.
Reference article: How LinkedIn’s password sloppiness hurts us all by Jeremi M. Gosney
If [online services] aren’t using something like bcrypt or Argon2 for password storage, then they’re doing things very, very wrong. But slow hashing is no longer as effective of a solution as it could have once been had it only been adopted sooner.
When you suspect a password database has been compromised, even just in part, you cash in on that insurance policy [of using forced password resets] immediately by activating your incident response team and your public relations team.
What is Argon2? It’s the winning algorithm from the Password Hashing Competition. Argon2 has been added to recent versions of libsodium.
I’ve been following the Ars coverage of the Oracle v Google trial regarding whether Google’s use of Java APIs is “fair use”. I didn’t think Google would win, but was pleasantly surprised when the jury decided in their favor. Hurrah!
However, just because Google won, doesn’t mean that companies can indiscriminately copy APIs and have it fall within “fair use”. It seems safest to me to make use of APIs that fall under an open source license. That way, the code individuals and companies write can more easily be run against competitive API implementations without being held hostage by the owners of the original API.
Ars has an interesting article showing how the internet works with regard to the underseas cables that tie the continents together. I had no idea there were repeaters to help the signal propagation, or how broken cables were repaired.
It’s useful to shorten long URLs, especially when sending them in tweets and in text messages. An LWN.net article helped me learn that they can be a security risk:
URL shorteners such as bit.ly and goo.gl perform a straightforward task: they turn long URLs into short ones, consisting of a domain name followed by a 5-, 6-, or 7-character token. This simple convenience feature turns out to have an unintended consequence. The tokens are so short that the entire set of URLs can be scanned by brute force. The actual, long URLs are thus effectively public and can be discovered by anyone with a little patience and a few machines at her disposal.
Around 7% of the OneDrive folders discovered in this fashion allow writing. This means that anyone who randomly scans bit.ly URLs will find thousands of unlocked OneDrive folders and can modify existing files in them or upload arbitrary content
— VITALY SHMATIKOV
I ran across pictures by Albert Dros, displaying the beauty of the Netherlands. I lived there for two years as a missionary for the LDS Church. I spent much of my time on a bicycle, riding through wind and rain, and enjoying sunsets and the verdant landscape. I had the opportunity to visit Keukenhof and Kinderdijk, both beautiful places, and both featured in Dros’ photos.
Encrypting sensitive data-at-rest (i.e. in a database) is a good idea, but how does one manage the encryption keys, and rotate keys or start using a new algorithm down the road without orphaning or migrating the old data? Use KeyCzar
Cryptography is easy to get wrong. Developers can choose improper
cipher modes, use obsolete algorithms, compose primitives in an unsafe
manner, or fail to anticipate the need for key rotation. Keyczar
abstracts some of these details by choosing safe defaults,
automatically tagging outputs with key version information, and
providing a simple programming interface.
Keyczar is designed to be open, extensible, and cross-platform
compatible. It is not intended to replace existing cryptographic
libraries like OpenSSL, PyCrypto, or the Java JCE, and in fact is
built on these libraries.
Or learn from what Google did with KeyCzar, and implement the same ideas (key rotation and key version info) using a more modern encryption library, like libsodium.
I came across this recently, and I think it’s worth sharing. It outlines gotchas of commonly used commandline tools and arguments such as when ‘rm -rf’ doesn’t remove a directory, and how to get around it, or when ‘wc -l’ fails to count the last line in a file.
What happens when you have hundreds of services connected to RabbitMQ and memcache, and those services have a bug that causes them to keep their previous socket connections open, and repeatedly reconnect to RabbitMQ and memcache?
It occurred to me that one can prevent too many connections using iptables on the RabbitMQ and memcache machines. Here’s how:
The corollary is that setting the per-ip connection limit too low can also cause problems.
I’d guess that more commonly public-facing servers like NGINX and Apache don’t have the problem of crashing. Hopefully, they degrade gracefully, and refuse additional connections while continuing to service the connections they already have open.
It’s fun to learn about new command line tools from coworkers. Here are two.
- rlwrap can be used to wrap anything in a realine command history. It’s useful to preserve command history, including the commands typed in remote ssh sessions. Just wrap ssh in rlwrap.
- ag, the silver searcher, is a super-fast recursive grep tool. I enjoy using it, and am pleased at how quickly it returns search results on my source code trees.
I was glad to come up to speed with what has been happening with TLS in the last couple of years, and I highly recommend reading these articles.
I learned about HTTP Public Key Pinning, Certificate Transparency, and STARTTLS stripping, among other things.
Here’s one of many good quotes:
The core problem of the TLS certificate system is that there exist hundreds of certificate authorities. And unless extra protection measures are in place, each of those can create valid certificates for any domain. Therefore the whole system is only as strong as the weakest of all certificate authorities.
And as for embedded devices that handle encryption:
We are well aware that crypto appears to be something that needs to be field replaceable, and yet we more or less have no clue how to do that in deployed embedded hardware. Indeed, we seem to have a very poor idea in general on how to maintain the software on field deployed embedded hardware. — Perry Metzger
As I’ve worked with Python, I realize that it’s one thing to implement TLS, and another thing to verify server certificates. The Python requests library can be configured to do the right thing, but the python SMTP cannot. It’s still another thing to check on certificate revocation. Python doesn’t implement OCSP or CRLs, and those mechanisms are problematic anyway. It doesn’t yet implement HTTP Public Key Pinning. The state of affairs may not be much better in other programming toolboxes.
So I’d guess that machine to machine internet communication is probably more vulnerable to man in the middle attacks than consumer web browsers.