- 1 Passwords
- 2 Security and cryptography
- 2.1 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?
- 2.2 You use 1024 bit RSA keys for identity-file and securing clearing-communication. Isn't the length of 1024 bit too less?
- 2.3 Why don't you use PKI techniques and standards like S/MIME or PGP?
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:
- We have multiple premises that sometimes differ from other use-cases:
- 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.
- 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 he owns them). It also allows him to send in the name of the victim.
- 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 it now is insecure.
- Therefore, this are the detailed reasons we do not allow people to chose their initial password:
- If we allow more or less everything, we will get passwords like "password", "12345678" or "letmein". We all agree that this is not good.
- 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.
- 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.
- 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 job 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.
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 info (at) regify.com (subject "security questions").
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 p2/2n+1 (this is an approximation which is valid for "small" p, i.e. substantially smaller than 2n/2). For instance, with SHA-256 (n=256) and one billion messages (p=109) then the probability is about 4.3*10-60 (0.0000000000000000000000000000000000000000000000000000000000043%). Additionally, the message is not only compared against the message-hashcode. The recipients hashcode needs to match perfectly to this transaction, too. Upon this, the risk of a collision is very very low...
You use 1024 bit RSA keys for identity-file and securing clearing-communication. Isn't the length of 1024 bit too less?
First, since 2014, all regify providers are using 2048 bits as a default for every new identity-file!
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 message-key is stored directly in the clearing-service. The RSA encryption is used for two purposes:
- Securing the communication between regify-client and clearing. In this case, the encryption needs to "hold" only for the duration of of the communication process. Additionally it needs to "hold" for the time a attacker is willing to spend to break it. Please remark, that the channel where such message is gathered does not also contain the encrypted message. Thus, a hacker needs both: cracking the RSA key and find a way to get the message (which is moving from sender to recipient directly).
- Used as Private/Public key pair in the regify identity-file. This one is used to ensure the authentication of the user against his regify-provider. Additionally, the communication between the regify-client and the regify-provider is 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. is adequate here. Furthermore, 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 1024 bit for RSA enryption is an ideal compromise between security and speed.
Anyhow, each provider is able to raise the bitlength 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 as 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:
- regify is much easier to understand, to administrate and to handle.
- regify generates a confirmation of receipt.
- regify transactions are traceable and auditable at any time (history).
- you only have to know a persons email address to be able to send her a regify e-mail.
- you don't need to update certificate revocation lists, manage trust-center certificates or any other certificate servers.
- in the regify portal, you can manage representatives. Thus, a user can have his important e-mails processed in a controlled manner during his absence.
- and many others...
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