Security

Passwords

How about individual initial password?

Passwords (German only ;-) )

Sometimes we get asked why we do not allow users to chose their initial password by themselves. This is a complex question and we like to explain our current decision:

1. We have multiple premises that sometimes differ from other use-cases:
   1. We are providing a security related service. It is not a forum or something where someone might steal some money (which is in most cases insured). People trust that messages sent by regify are very secure and especially for authenticated users we need to make sure that this is always the case.
   2. Knowing the account credentials of some regify account gives an attacker the ability to open all RGF files that have been sent to the victim (if the attacker gets access to them). It also allows him to send in the name of the victim.
   3. Even if an account was abused because of a weak password, the press will write that some regify account has been "hacked" (which is wrong, but many journalists do not understand). From the perspective of the public, regify now is insecure.
2. Therefore, this are the detailed reasons we do not allow people to chose their initial password:
   1. If we allow more or less everything, we will get passwords like "password", "12345678" or "letmein". We all agree that this is not good.
   2. If we establish rules like "minimum 8 characters, upper and lower-case and at least one number" we still will get passwords like "Donald123" or "Passw0rd". You can see that such rules will never prevent users from choosing weak passwords.
   3. If the rules are very strict, users will not be able to use their "common" password any more. This forces people to simply add numbers or double the password. For example, instead of "Clara1" they will chose "Clara1Clara1". In such case, most people do not remember the password later anyway.
   4. If the rules are very strict, users are bugged about the system because it denies most of their ideas. This lowers consumer satisfaction and we decided to not do this in the registration process.

If choosing your own password is allowed in the provider portal depends on the regify provider configuration settings. Most providers allow you to choose your password later. Just log in and enter your own ("My account" -> "New password"). Of course, this password is also measured for security. But not by a simple algorithm like described above.

If you are using the regify provider SDK to create users, you can also submit the password. There is also a SDK function available to directly set and change the password for existing users. In both cases, the regify provider SDK must be called from a user with SUPER USER permissions.

More about common passwords through the years on Wikipedia

Isn't eight characters way too little?

If we would secure the regify messages using this password, the answer would be yes. Like for ZIP archives and any other file encryption. But the regify password is not used for any file encryption. It is used for login at the regify provider system only (online, web browser and all client software and APIs). So brute force attacks are much slower. Also, the regify provider reduces the number of login attempts to a given regify account to one per minute after it failed for more than 10 times (this also applies to a distributed brute force attack).

We also consider our randomly generated 8 character passwords more secure than any 12 digits user generated password. But anyway, every regify provider is able to increase the number of characters for the initial password by himself.

How are the passwords stored in the regify provider appliance database?

Due to technical reasons (like the provider lookup service PLS and cross-provider password reset), we save the SHA1 hashcodes of the passwords. But they are additionally encrypted using AES256 encryption with individual random IV and the SHA256 hashcode of the regify provider clearing password as key. This clearing password is never stored in the database and exists only in a local file outside of the web root. By this, SQL-injection attacks and database leaks are not able to leak passwords directly.

How do I force users to change passwords periodically?

There is no such function in the regify provider. We follow the current guides of NIST (US), CESG (UK) and BSI (DE). Due to research and security experts consent, forcing users to change their password does not increase security. Instead, it very often reduces security because people tend to use more simple passwords and also follow some predictable evolution (like password1, password2, password3 etc.). Password changes are only needed in case the password is compromised in some way.

2FA

We're occasionally asked about 2FA (two-factor authentication) in regify products. Please read this chapter to understand the facts.

Opening a payslip in regipay Classic, a regimail message or a regibox invitation, requires the user to have both regify credentials and the email containing the rgf file. Therefore, sending 2FA confirmation emails is not an option because hijacking an email account is the only vulnerability we're talking about. Loosing the regify account password (e.g. by phishing) is not sufficient to allow someone to read regipay Classic or regimail messages.

Most of our customers are unwilling to pay for text messages (SMS), voice calls or hardware tokens. Also, it is difficult to estimate the cost because around 30% of users cannot remember or note their regify account password and need to reset it every month. This would require a significant number of SMS messages or calls. Prices for hardware tokens (OTP) are also usually too high.

Finally, biometrics are usually only available on mobile devices, not on Desktop PCs with Windows, Linux or MacOS. Desktop users are either not used to it or lack the technical ability to implement it.

Therefore, only TOTP solutions with Authenticator apps remain. In our experience, many users are either annoyed by this or unwilling or unable to use Authenticator apps (e.g. because they don't have a mobile or the necessary technical ability). Our solutions, especially regipay, are apps for everyone and not just for people who are used to IT.

For this reason, we currently only offer partial 2FA. For regimail professional users (paying regimail users), they can use a mobile number and SMS for signing up. This is then also required for any password resets. By this, a hijacked email account is not sufficient for a regify account password reset.

However, if you are interested in full 2FA, please contact our sales team at sales[at]regify.com to discuss options for integrating 2FA for your company or organisation.

NOTE: Please note that most regipay and regimail client apps offer optional local protection using a user-defined app password. This is not a replacement for 2FA but offers additional security. If entered, it is asked for whenever the app is used to open a regipay payslip or a regimail and protects against abuse on lost or shared devices.

Security and cryptography

This paragraph is intended to answer the questions of security experts that like to have a deeper look at the regify-service. If you are an expert having additional questions, please feel free to send us an e-mail at support (at) regify.com (subject "security questions").

What encryption algorithms is regify using?

All regify products today are using AES256 encryption algorithm to encrypt messages (regimails, regipay, regibox invitations etc). Here we are using the CBC block cipher mode with random IV.

Client to regify Clearing communication is using ECC encryption with Curve25519 or, in some older applications, RSA with 2048 bits or more.

Client to regify Provider communication is using RSA with 2048 bits or more.

All hashcodes are calculated using SHA256 algorithm.

If you are interested in knowing the exact usage of encryption and the communication protocols in detail, please contact us at support (at) regify.com.

You use SHA256 hashcodes to find the message-keys in the clearing database. Isn't there a high risk in collisions that may leak security?

If we have a "perfect" hash function with output size n, and we have p messages to hash (individual message length is not important), then the probability of a collision is about p²/2ⁿ⁺¹ (this is an approximation which is valid for "small" p, i.e. substantially smaller than 2^n/2). For instance, with SHA-256 (n=256) and one billion regify messages (p=10⁹) then the probability is about 4.3*10^-60 (0.0000000000000000000000000000000000000000000000000000000000043%). Additionally, the regify message is not only compared against the message-hashcode. The recipients hashcode needs to match perfectly to this regify transaction, too. Upon this, the risk of a collision is very very low...

Reference: http://en.wikipedia.org/wiki/Birthday_Paradox

You use 2048 bit RSA keys for identity-file and securing clearing-communication. Isn't that to less?

In general, you need to keep in mind, that the regify system does not encrypt the messages itself using these RSA keys. The messages are getting encrypted using AES256 and the random message-key is stored directly in the clearing-service (new key for every message). Don't compare this to hybrid encryption in other products. The identity-file is not used for hybrid encryption like in PGP and S/MIME. So the assumptions you do may not apply. The integrity and security of the messages is not affected by the identity-file. Instead, the identity-file is used to ensure identity of the sender and recipient against his regify provider during login only (for sending and receiving). It even can get exchanged whenever you want without affecting readability or security of the regify messages itself.

Also, even RSA with 1024 bits is far from getting hacked. Please refer to the RSA Factoring Challenge. In February 2020, RSA with 829 bits was broken. Everything above is still considered secure today.

The RSA encryption is used by regify for two purposes:

1. Securing the communication between regify client and clearing. We used RSA with 2048 bits until 2018. In 2018, the regify client software started to use Elliptic Curve encryption (ECC) using Curve25519 algorithm for clearing communication. This does not only increase the robustness of this part of the encryption, it also uses less CPU power and speeds up communication. During 2018 and 2019, more and more regify products were migrated to use ECC. Since 2020, all regify software is using ECC for clearing communication.
2. Used as Private/Public key pair in the regify identity-file. This one is used to ensure authenticity of the user against his regify provider. Additionally, the communication between the regify client and the regify provider is additionally secured by this keys. As the messages itself are not associated in any way with this identity-file, the identity-file can get renewed as often as the customer likes to. Upon this, the same answer as on 1. Furthermore, please also note that even if the identity file content is known by an attacker, the login protocol is not broken and no data is leaked. The message key is still additional encrypted using the clearing keys. Finally, the used algorithms and bitlength can get changed at any time in the future - without having any effect on the message accessibility.

Upon these facts, and contrary to PKI solutions, using 2048 bit RSA encryption as identity file is an ideal compromise between security and speed.

Anyhow, each provider is able to raise the bitlength for identity-files up to 3072 or even 4096 bits for his individual preference.

Why don't you use PKI techniques and standards like S/MIME or PGP?

regify does not work like PGP or other PKI methods. The benefits of the regify-system would not have been possible, if we would use these standards. The benefits, that are resulting directly on the abstinence of standard PKI techniques, are listed on our homepage in the regimail FAQ section.

Update May 2018:
It turns out that PGP and S/MIME emails are insecure by design. It is highly recommended to observe the future development of these standards and carefully make decisions about this.

Short article: Independent UK
Details: Detailed information from the ones who found the issue Bruce Schneier on New PGP Vulnerability

Update July 2019:
The PGP Problem

Connection protocol

You want to know more details about our regify connection protocol? No problem, just send us an email to support(at)regify.com and tell us why you're interested. We will send you the documents then.