Cryptography in the perc.pass password manager
Cryptography and perc.pass
Content:
Cryptography
What is a cryptographic key?
Why can’t we encrypt using passwords alone? They are bits too, aren’t they?
What is the point of all this?
When we began our journey to realize the idea of a web-based password manager, the team was filled with an atmosphere of great excitement, mixed with a flood of ideas for solving the everyday problems of navigating the digital world. The full awareness of the responsibility for users’ passwords came later.
When the moment of implementation arrived – when we had to figure out how to fulfill all those beautiful-sounding ideas – it turned out that the problem was by no means trivial. That was when we began to discover why, until now, no one in Poland had taken on the challenge, and why a homegrown Polish password manager had not yet succeeded on our local market.
In this and future articles, I will try to present, from a technical and analytical perspective, how we made perc.pass a secure cryptosystem and ensured that operations are as decentralized as possible (meaning they happen on the user’s side).
Before I move on to the most substantively interesting topics, I will try to explain in simple terms all the necessary concepts, technicalities, and standards needed to understand our approach to securing organizational data. The topics I will cover correspond 100% to the product’s implementation and align with all requirements related to GDPR, ISO:27001, and meet the recommendations of cybersecurity organizations.
So, what is this cryptography?
In a strict sense, it is a branch of knowledge on the border of mathematics and computer science concerning the concealment of messages. It is not about hiding the fact that a message exists (steganography). Cryptography is intended to protect a message from unauthorized access, even when others have access to the entire information (the ciphertext).
Cryptographic techniques utilize many well-known encryption algorithms, which are mathematical functions usually based on solid mathematical foundations. It is these functions that perform the actual encryption or decryption. Good algorithms are generally publicly known, and their strength is based on the secrecy of the keys used.
A cryptographic key?
Yes, in cryptography, keys are used which, much like those for padlocks, guard access to our data. This term is commonly used to describe a sequence of bits used by an algorithm to transform data from plaintext to encrypted form or vice versa. Their length is a very important parameter in cryptographic systems; the longer they are, the greater security they provide and the harder they are to guess. However, this introduces additional overhead on operation time, so a compromise is necessary.
Cryptographic algorithms are currently divided into two groups based on the keys used:
- symmetric algorithms
- asymmetric algorithms
Symmetric cryptography uses exactly the same key for both encryption and decryption, which is agreed upon by both parties before communication begins. The key must strictly remain known only to the parties involved in the communication. Its disclosure results in the disclosure of the secret message, as it can simply be decrypted. These algorithms are significantly faster than asymmetric ones because most of them rely on simple transformations: substitutions and transpositions.
Asymmetric cryptography uses a pair of keys in the communication process: a public key and a private key. The private key, as its name suggests, must strictly remain known only to the owner. The public key, however, is intended for anyone to know and use. In this way, a message encrypted by anyone using a specific owner’s public key can only be decrypted by the private key held by that owner. In this case, the encryption and decryption algorithms are identical. They are based on mathematical functions rather than substitution and transposition, which is why they are significantly slower in operation than symmetric algorithms.
As a side note, the entire digital signature infrastructure is oriented toward asymmetric cryptography. In that situation, the reverse operation is used – document hashes are encrypted using the private key (which only the owner possesses) so they can be decrypted with the public key (which is well-known, providing certainty that it belongs to a given person, thereby verifying the signature).
In perc.pass, we use both types of cryptographic algorithms to secure data and the users’ keys themselves, which is why it is so important to understand where all these schemes come from.
To complete the basic knowledge of how cryptography works in the perc.pass password manager, we must mention so-called cryptographic hash functions or one-way hash functions. Both terms mean the same thing: mathematical functions that generate a short value of a fixed length based on data of any length. A good hash function should, with high probability, generate different results for different input data. These tools are characterized by the irreversibility of mathematical operations; the only way to “break” them is to guess the input data, which is a Herculean task at best.
Hash functions are also used to generate symmetric cryptographic keys based on input data. Combining them with additional security mechanisms allows passwords to be used in cryptography. PBKDF (Password-Based Key Derivation Function) represents a family of functions used to generate cryptographic keys from passwords. They take the user’s password and a certain computational cost as input. Optionally, a “salt” can be applied – a sequence of bits that further obscures the result. The result is a pseudo-random key that can be used for operations.
Why can’t we encrypt using passwords alone? They are bits too!
Such an encryption process would be doomed to failure from the start because our passwords are most often words and numbers. Passwords with special characters are rarely memorized. Such keys could be guessed very quickly using simple dictionary attacks, granting immediate access to the decrypted message.
However, when a key is derived from a simple password like “password” using that password and hashes calculated over a certain number of iterations, the situation is no longer so simple. Guessing the key becomes much more time-consuming for an attacker because every attempt must also involve calculating the hash function, for example, 600,000 times.
In perc.pass, we naturally use the PBKDF2 function to generate the Master Key, the specification of which is described in the RFC 2898 document (https://www.ietf.org/rfc/rfc2898.txt). It is with this function that the user’s Master Password is processed. This is why a user can set the number of iterations during activation. According to OWASP recommendations, 600,000 iterations should currently be set, which is why perc.pass establishes this value as the minimum.
Alright, but what is the point of all this?
At the beginning of the article, I wrote that I don’t entirely agree that users are “entrusting” us with their passwords. From their perspective – of course, these are passwords entered into a web application in plaintext. However, the cryptography described here serves primarily one purpose: so that we, as the software and Data Center space providers, have absolutely no insight into our users’ sensitive data!
And that is indeed the case, because the only things stored in our infrastructure are the ciphertexts of passwords and attachments that reach us from users. And the best part – they are encrypted yet again during communication using standard SSL/TLS, and also during storage in our databases. So, on our end, there are only ciphertexts of ciphertexts and some insignificant metadata.
Encryption schemes are a very interesting subject that we spent a long time analyzing, but I will cover that in future articles.
Looking to enhance your cybersecurity?
Contact us!
Leave your details – we’ll call you back
Our specialist will get back to you no later than the next business day. You don’t have to fill in the message field, but a brief note about the topic you’re interested in will be a valuable hint for us.
