[DB] Research user account management

a24vinla commented

2026-04-07 08:28:25 +00:00

Collaborator

How should we store account information in a primarily safe, but also efficient manner.

Parent Issues: #1 #9 #11
Related Issues: #143 #141

How should we store account information in a primarily safe, but also efficient manner. Parent Issues: #1 #9 #11 Related Issues: #143 #141

a24vinla added the

security

project documentation

research

labels

2026-04-07 08:28:25 +00:00

c24elipe commented

2026-04-07 13:00:49 +00:00

Collaborator

I just want to name-drop JWT tokens here for future discussion on the subject

b24krila was assigned by b24johka

2026-04-07 14:32:33 +00:00

b24krila commented

2026-04-07 15:38:43 +00:00

Collaborator

This is more focused on how we can store and handle the data rather then how its transmitted:

Account credentials are stored in a standard user table with for example an ID as a unique identifier and email as a login identifier. But we should not store passwords directly rather we should instead, hash each password using a random salt and a slow hashing algorithm such as Argon2, bcrypt or PBKDF2. This approach means that we only store the resulting hash, the salt used to generate it and the parameters of the hashing algorithm.

Since hashing is one-way, the original password cannot be recovered even if the database is compromised and the use of a unique salt for every user will prevent "rainbow table attacks" and slow hashing algorithms make brute-force attempts expensive for an attacker while remaining efficient for normal authentication.

During login, the system gets the stored salt and hashing parameters, then hashes the password entered by the user using the same method and then compares the result to the stored hash. If the values match, the user is successfully authenticated without ever exposing or storing the actual password.

This is more focused on how we can store and handle the data rather then how its transmitted: Account credentials are stored in a standard user table with for example an ID as a unique identifier and email as a login identifier. But we should not store passwords directly rather we should instead, hash each password using a random salt and a slow hashing algorithm such as Argon2, bcrypt or PBKDF2. This approach means that we only store the resulting hash, the salt used to generate it and the parameters of the hashing algorithm. Since hashing is one-way, the original password cannot be recovered even if the database is compromised and the use of a unique salt for every user will prevent "rainbow table attacks" and slow hashing algorithms make brute-force attempts expensive for an attacker while remaining efficient for normal authentication. During login, the system gets the stored salt and hashing parameters, then hashes the password entered by the user using the same method and then compares the result to the stored hash. If the values match, the user is successfully authenticated without ever exposing or storing the actual password.

b24krila added the

needs review

label

2026-04-07 15:38:52 +00:00

a24danwe commented

2026-04-08 10:18:44 +00:00

Collaborator

assign me

a24danwe commented

2026-04-08 13:17:01 +00:00

Collaborator

I have reviewed the researched solution regarding secure account information storage.

The research is good and follows a standard security practices for storing credentials.

It would be good to specify the advantages and disadvantages of using Argon2, bcrypt, and PBKDF2, and also suggest a preferred option and why.

Additionally, the efficiency aspect mentioned in the issue is not addressed, it would be good to add something about how to increase efficiency, such as tuning hashing cost.

I have reviewed the researched solution regarding secure account information storage. The research is good and follows a standard security practices for storing credentials. It would be good to specify the advantages and disadvantages of using Argon2, bcrypt, and PBKDF2, and also suggest a preferred option and why. Additionally, the efficiency aspect mentioned in the issue is not addressed, it would be good to add something about how to increase efficiency, such as tuning hashing cost.

b24krila removed the

needs review

label

2026-04-09 09:48:51 +00:00

b24krila commented

2026-04-09 10:56:17 +00:00

Collaborator

Argon2 (Argon2id)

Advantages

Designed to resist GPU/ASIC attacks through memory hardness,
Highly configurable, means that you can configure memory, time (iterations), parallelism,
Considered modern best practice,
Won the PHC (Password hashing competition) in 2015.

Disadvantages

Quite Complex to configure therefore requires careful parameter tuning,
not available in very old libraries or legacy systems.

bcrypt

Advantages

Widely supported and tested,
A single work factor (cost) makes configuration simple,
Resistant to brute force through computational cost.

Disadvantages

Not memory-hard so more vulnerable to GPU/ASIC attacks,
Has a 72-byte limit on password length.

PBKDF2

Advantages

Standardized,
Available in most languages and frameworks,
Easy to implement.

Disadvantages

Purely CPU-bound and not memory-hard making it weaker against GPU/ASIC attacks,
Requires high iteration counts for strong security.

Preferred option:

Argon2id is probably to recommend as the most suitable algorithm specifically (Argon2id), as it is designed to be resistant to both GPU and ASIC attacks, making large-scale brute-force attacks significantly more expensive for an attacker than bcrypt or PBKDF2.

bcrypt can be an acceptable alternative incase Argon2id is not available as Argon2id is newer and don't support very old libraries and legacy systems. And PBKDF2 should only be used when required.

Performance

Slow hashing algorithms add intentional computational costs to protect from brute-force attacks, however this cost must be balanced to avoid degrading the performance off authentication for the users.

Argon2id is suitable here as well as it allows the tuning of its cost parameters specifically memory cost, time (iterations) cost and parallelism.

To balance the security and performance we can set some "hard" rules such as:

The hashing process should take "x" time which should be noticeable but acceptable amount of time, so that it does not impact the user experience while it still slows down brute-force attempts.
The parameters should be set in a way, so that the authentication process remains responsive at all times.
The parameters can and should be reviewed periodically and then adjusted based on performance changes over time.

Links used during research:

Recommending the last link if you want to read and understand the differences quickly.
What is bcrypt
What is Argon2
Password Hashing: Scrypt, Bcrypt and ARGON2
Complete Guide to PBKDF2 vs bcrypt vs Argon2 for Password Hashing

### Argon2 (Argon2id) **Advantages** - Designed to resist GPU/ASIC attacks through memory hardness, - Highly configurable, means that you can configure memory, time (iterations), parallelism, - Considered modern best practice, - Won the PHC (Password hashing competition) in 2015. **Disadvantages** - Quite Complex to configure therefore requires careful parameter tuning, - not available in very old libraries or legacy systems. ### bcrypt **Advantages** - Widely supported and tested, - A single work factor (cost) makes configuration simple, - Resistant to brute force through computational cost. **Disadvantages** - Not memory-hard so more vulnerable to GPU/ASIC attacks, - Has a 72-byte limit on password length. ### PBKDF2 **Advantages** - Standardized, - Available in most languages and frameworks, - Easy to implement. **Disadvantages** - Purely CPU-bound and not memory-hard making it weaker against GPU/ASIC attacks, - Requires high iteration counts for strong security. ### Preferred option: Argon2id is probably to recommend as the most suitable algorithm specifically (Argon2id), as it is designed to be resistant to both GPU and ASIC attacks, making large-scale brute-force attacks significantly more expensive for an attacker than bcrypt or PBKDF2. bcrypt can be an acceptable alternative incase Argon2id is not available as Argon2id is newer and don't support very old libraries and legacy systems. And PBKDF2 should only be used when required. ### Performance Slow hashing algorithms add intentional computational costs to protect from brute-force attacks, however this cost must be balanced to avoid degrading the performance off authentication for the users. Argon2id is suitable here as well as it allows the tuning of its cost parameters specifically memory cost, time (iterations) cost and parallelism. To balance the security and performance we can set some "hard" rules such as: - The hashing process should take "x" time which should be noticeable but acceptable amount of time, so that it does not impact the user experience while it still slows down brute-force attempts. - The parameters should be set in a way, so that the authentication process remains responsive at all times. - The parameters can and should be reviewed periodically and then adjusted based on performance changes over time. ### Links used during research: - Recommending the last link if you want to read and understand the differences quickly. - [ What is bcrypt](https://jumpcloud.com/it-index/what-is-bcrypt) - [What is Argon2](https://jumpcloud.com/it-index/what-is-argon2) - [Password Hashing: Scrypt, Bcrypt and ARGON2](https://medium.com/@mpreziuso/password-hashing-pbkdf2-scrypt-bcrypt-and-argon2-e25aaf41598e) - [Complete Guide to PBKDF2 vs bcrypt vs Argon2 for Password Hashing](https://www.locksy.dev/blog/complete-guide-to-pbkdf2-vs-bcrypt-vs-argon2-for-password-hashing)

b24krila added the

needs review

label

2026-04-09 10:58:29 +00:00

b24idalu was assigned by c24elipe

2026-04-09 11:30:40 +00:00

b24idalu commented

2026-04-09 12:32:23 +00:00

Collaborator

I've reviewed ways to store passwords safely and efficiently in DB

There are different methods that are compared to each other, which is good. There is also a preferred method which is appropriately motivated. Good suggestions with the rules for optimal performance.

Could have been good to write a bit about how the different methods work and not only the pros and cons, but by reading the links one can figure it out. Am wondering a bit about protection of other data other than passwords, for example if we are storing emails for teachers? How do we keep that safe?

I've reviewed ways to store passwords safely and efficiently in DB There are different methods that are compared to each other, which is good. There is also a preferred method which is appropriately motivated. Good suggestions with the rules for optimal performance. Could have been good to write a bit about how the different methods work and not only the pros and cons, but by reading the links one can figure it out. Am wondering a bit about protection of other data other than passwords, for example if we are storing emails for teachers? How do we keep that safe?

b24krila removed the

needs review

label

2026-04-09 12:47:42 +00:00

c24elipe added the

reviewed

label

2026-04-09 12:55:53 +00:00

b24krila commented

2026-04-09 13:17:25 +00:00

Collaborator

Good points.

How they work

Argon2id: Combines the memory-hard computations and multiple passes to resist GPU/ASIC attacks, combined with a data-dependent and data-independent memory access.
bcrypt: uses the blowfish cipher internally and repeatedly applies it to the password + salt
PBKDF2: applies a standard hash function such as (SHA-256) to the password + salt and hashes the password + salt multiple times, potentially even thousands to hundreds of thousands times

Other sensitive data such as emails.

Encryption at rest, encrypt sensitive data using a strong algorithm such as AES-256.
If we encrypt data that is frequently accesses such as emails, then we can store a hashed version for lookups while keeping the full email encrypted.
Access control, we can implement role-based rights to restrict who can access sensitive fields
Transport security, we always use secure protocols when sending or receiving sensitive data (e.g., HTTPS)

Good points. ### How they work - Argon2id: Combines the memory-hard computations and multiple passes to resist GPU/ASIC attacks, combined with a data-dependent and data-independent memory access. - bcrypt: uses the blowfish cipher internally and repeatedly applies it to the password + salt - PBKDF2: applies a standard hash function such as (SHA-256) to the password + salt and hashes the password + salt multiple times, potentially even thousands to hundreds of thousands times ### Other sensitive data such as emails. - Encryption at rest, encrypt sensitive data using a strong algorithm such as AES-256. - If we encrypt data that is frequently accesses such as emails, then we can store a hashed version for lookups while keeping the full email encrypted. - Access control, we can implement role-based rights to restrict who can access sensitive fields - Transport security, we always use secure protocols when sending or receiving sensitive data (e.g., HTTPS)

b24krila added

needs review

and removed

reviewed

labels

2026-04-09 13:31:21 +00:00

b24idalu commented

2026-04-09 14:05:54 +00:00

Collaborator

Sounds like good research! I have nothing more to add

b24krila added

reviewed