Refine and document our authentication and security mechanisms

[steve-hb]

We have to refine & document our authentication and security mechanisms.
The current documentation (#31) is included in our graphql schema which is tbh not that great.

Task for refinement: We should use the strength of PBKDF2 and generate random salts for every user which we send to the frontend to stretch the password hashing.
(see https://en.wikipedia.org/wiki/PBKDF2#Purpose_and_operation)

@TheMorpheus407 and @iiestIT could maybe assist us here.

[steve-hb]

This task also includes flow diagrams showing which application sends which data for what purpose to which micro service.
Related: brute force, ip/user ban (#14), DoS protection, deviceId (https://owasp.org/www-community/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies)

[steve-hb]

Maybe this is an epic? I think so:

• Refine authentication/security concept (Refine and document our authentication and security mechanisms #32)
• Document authentication concept (Document authentication (Epic: #32) #34)
• Document authentication security (Document authentication security (Epic: #32) #35)
• Token documentation (Document the structure of every token (Epic: #32) #36)

[steve-hb]

Ah, I forgot something: Service Auth Tokens! We use them for authentication between our micro services to ensure that even an "open" micro service won't accept every request - which should never happen, but who knows? Errare humanum est!

// This would also mean we have to document the headers used for these tokens
@RedstoneMedia I think u or ur team specified this, didn't they?

[JavaDerg]

We have to refine & document our authentication and security mechanisms.
The current documentation (#31) is included in our graphql schema which is tbh not that great.

Task for refinement: We should use the strength of PBKDF2 and generate random salts for every user which we send to the frontend to stretch the password hashing.
(see https://en.wikipedia.org/wiki/PBKDF2#Purpose_and_operation)

@TheMorpheus407 and @iiestIT could maybe assist us here.
Relating to #31
I don't see the issue here, the documentation certainly needs refinement but the we do need to send the password to the server so it can get verifies using the Bcrypt algorithm.
Using this algorithm we don't need to store a seperate salt, because one is already included in the hash.
Or do I miss understand something?