Same salt added to each ssn

[Yaamboo]

In src/main/java/fi/om/initiative/service/EncryptionService.java

See discussion here: https://www.facebook.com/villoks/posts/10152374146229179:0?stream_ref=1

[ssaarela]

As noted in the discussion, there is a configured global shared secret that is appended to the hash. The purpose of this hash is to prevent intentional as well as unintentional duplicate voting. Without it the system could not tell whether the logged in user has already voted some initiative or not. Actual support note details consists of natural ID of the person (name, birthdate and home town). These details are strongly encrypted in order to protected the identity of the citizens. Of course, this natural ID could be used as a key instead of SSN, but that would be unreliable. Firstly there are people having same name and birthdate. Secondly, in some cases user needs to supply his or her home town him or herself.

There was also a question of recursive hash iteration count. The point of iterations is to increase the penalty of hash calculation in order to make brute force harder, i.e. more time consuming - in that regard the purpose is the same as salt’s. For simplicity, at the beginning iteration count was chosen to be one. But the point is absolutely valid: iteration count should be dynamic (per initiative), and it is a very good suggestion! I would also consider making the actual hash algorithm (e.g. bcrypt) dynamic so that the penalty for brute force can be further increased easily in the future.

SSN is not the only sensitive information in this system. Profiling information about what people have supported is “very interesting”. In this regard, there is salt as initiative id is part of the hash. This restricts the scope of brute force (e.g. dictionary attack) to a single initiative. The important thing to note here is that there is no way other than brute force to get a list of initiatives some person has supported. The question of salt or no salt boils down to a question of the scope of the salt. Even with passwords the salt needs to be plain text beside the hash so that the validity of a user supplied password can be checked at login. In kansalaisaloite.fi the scope is by design single initiative, not individual support vote, as this would negate the purpose of the hash.

[panuhorsmalahti]

bcrypt's default iteration count is 2^10, but I'd probably start at 2^14. It's trivial to increase the iteration count in the future, as bcrypt is designed to support that. The only change that's required is to update the constant and replace the the old hash with the new one on login.

Currently registeredUserHash consists of the SSN and 'a configured global shared secret '. It must be assumed that the attacker can find out this global secret, because it's available to the system in plaintext. Next, the attacker can download the database and start a brute-force attack. Since the attacker knows the shared secret, and also knows the date of birth (which apparently is stored in plain-text), he only needs to run a few thousand iterations of SHA-256, and find out the SSN. It would therefore be pretty cheap to get all the social security numbers of all users.

Using bcrypt you can increase the cost arbitrarily, but it would still be problematic. For example, with a iteration count of 2^16, there would be 65536*2000 calculations to break one SSN.

The problem with SSN is that it's in practise used for authentication. If you call a hospital and you know someone's name and SSN, you'll likely get that person's medical history. Of course, that might be a mistake by the hospital, but if we're pragmatic, the storing of SSN should be avoided if possible.

[ssaarela]

Only initiative authors and officials are such registered users. We need to identify them as individuals. Unfortunately there is no other reliable ID than SSN with witch to identify Vetuma-authenticated users. ID provided by Vetuma depends on the authentication method chosen by the user. Alternatives are phone number, SATU, username or HETU. Of these, HETU is the only one that is also always available. Please correct, if there is other reliable ID available from Vetuma.