With the breach of LastPass and everyone wondering if their vaults will be impervious to attacks. I thought it might be good time to refresh our understanding on two type of encryption. Once we do that let's talk about encryption in password managers.
There are two classes of encryption, but until 1976 symmetric key encryption was the only show in town. It involves a shared key used to encrypt and decrypt messages.
First up we have symmetric key encryption. This requires the successful sharing of a shared key. If someone gets hold of this key its allows them to decrypt any message they intercept and also encrypt its own messages.
Asymmetric encryption uses a mathematically related pair of keys for encryption and decryption: a public key and a private key.
You can encrypt data with either key, but only its pair can decrypt it. The main benefit of this type of encryption is that you can keep your private key entirely private and publicly share the public key, which people can use to encrypt data for you.
Here is the original paper that introduced public key encryption. Called New Directions in Cryptography by Whitfield Diffie and Martin Hellman. ee.stanford.edu/~hellman/publi…
So now back to breach specifics around LastPass.
The main fault here is how they didn't include sensitive metadata like websites URLs in the encrypted payload. Which opens up their customers to social engineering attacks. If you didn't have a strong password, it makes it hard to ensure long term security of your data.
If the number of rounds of PBKDF2 were lower and/or your password wasn't strong cracking these vaults isn't out of the question. There were reports of hashing rounds as low as 5000. With attacker with the right amount of resources this might be possible to crack.
Platforms like @1Password also have a secret key in addition to master password which makes the process much more difficult as well as encrypting all associated metadata that could be an attack vector.
Even if an attacker were to get your encrypted vault data and guess your password they still wouldn't be able to access your encrypted vault data without secret key which you should also guard like a password. Hence the two-secret key derivation.
If want to learn more about encryption we have a more in depth post coming up soon at architecturenotes.co join us and don’t miss out.
Enjoyed this thread?
Follow @arcnotes and subscribe to the newsletter here
Simon Willison (@simonw), the creator of Datasette, writes about SQLite and the challenges of building a server-side web application that also works in Electron and WebAssembly. It's a great read — I hope you enjoy it and hopefully learn something.
Datasette datasette.io is a tool for exploring and publishing data. The original goal of the project was to make it easy and inexpensive to publish structured datasets online.
The Python Global Interpreter Lock or GIL, in simple words, is a mutex (or a lock) that allows only one thread to hold the control of the Python interpreter.
Python uses reference counting for memory management, leading to a race condition if multiple threads have access.
It is often surprising how little is known about how databases operate at a surface level, considering they store almost all of the states in our applications. Things You Should Know About Databases.
Indexes are a data structure that helps decrease the look-up time of requested data. Indexes achieve this with the additional costs of storage, memory, and keeping it up to date (slower writes), which allows us to skip the tedious task of checking every table row.
So here is where most developers go – I have seen this problem before; we need some dictionary (hash map) and a way to get to the specific row we are looking for. These are called index leaf nodes.
A deep technical dive into all things Redis. Covering various Redis topologies, data persistence and process forking.
Redis redis.io (“REmote DIctionary Service”) is an open-source key-value database server.
The most accurate description of Redis is that it's a data structure server. This specific nature of Redis has led to much of its popularity and adoption amongst developers.
There is often a level of focus on the bigger picture when it comes to system design, but we often don't think about the underlying components in these systems. So let's chat about different levels of memory.
Over the years memory has increased in capacity and in speed as you can see with the chart below it's been following a trajectory called Moore's law.
There are several types of RAM; the two main types are SRAM and DRAM. SRAM is more closely associated with CPU caches and provides lower latency but are more expensive. Meanwhile DRAM is slower but much cheaper and can be packed densely, which makes it ideal for main memory.
There are many discussions about which level of system granulation is the best. We went from monoliths to microservices and back again. Today we will break it down.. a bit.
The big kahuna, the monolith! Most systems start here, and I would argue most systems should stay here. Monoliths are deployed and developed as a single unit. It contains all the functionality that the application supports, from UI to the database.
Pros:
• Early on, simpler and faster development
• Performant
• Fewer cross-functional concerns, and if there are easier to grok them.
Cons:
• As complexity and size increase, so does the agility of the said system
• Larger systems changes become more complex.
Latency. Latency. You hear about this every day. Understanding latency is essential in all parts of our systems, including registers, main memory, disk, and network. In addition, understanding these latencies is vital so you can reason about various aspects of your system.
Latency is physically a consequence of the limited velocity at which any physical interaction can propagate, which is always < speed of light.
Latency always tends to sneak up on you. Oh, 1ms per item processing isn't bad. What if I had to process a billion items? That's just over 11 days. 🤯