From defb93ba7fbeee5ee0ce5bf978ea75e4c1cd7f4a Mon Sep 17 00:00:00 2001 From: Einhornimmond Date: Mon, 13 Sep 2021 16:33:24 +0200 Subject: [PATCH] my thoughts to jwt --- .../Snippets/Authorization/concept.md | 28 +++++++++++++++++++ docu/Concepts/Snippets/Authorization/jwt.md | 20 +++++++++++++ .../Snippets/Authorization/session_id.md | 16 +++++++++++ 3 files changed, 64 insertions(+) create mode 100644 docu/Concepts/Snippets/Authorization/concept.md create mode 100644 docu/Concepts/Snippets/Authorization/jwt.md create mode 100644 docu/Concepts/Snippets/Authorization/session_id.md diff --git a/docu/Concepts/Snippets/Authorization/concept.md b/docu/Concepts/Snippets/Authorization/concept.md new file mode 100644 index 000000000..5d189b3be --- /dev/null +++ b/docu/Concepts/Snippets/Authorization/concept.md @@ -0,0 +1,28 @@ +# Authorization and Private Keys +## Keys +For creating transactions ed25519 keys are used for signing. +As long the user is the only controlling the private key he is the only one +how can sign transactions on his behalf. +It is a core concept of all crypto currencies and important for the concept, +that the user has full control over his data. + +Usually crypto currencies like bitcoin or iota save the keys on local system, +maybe additional protected with a password which is used to encrypt the keys. + +## Gradido +Gradido should be easy to use, so we must offer a solution for everyone not that fit +with computer, as easy to use like paypal. +For that role we have the Login-Server. +It stores the private keys of the user encrypted with there email and password. +Additional it stores the passphrase which can be used to generate the private key, +encryted with server admin public key. So only the server admin can access the keys +with his private key. [not done yet] +It is needed for passwort reset if a user has forgetten his password. + +But for the entire concept Login-Server isn't the only way to store the private keys. +For users which has more experience with computer and especially with crypto currencies +it should be a way to keep there private keys by themselfs. + +For example a Desktop- or Handy-App which store the keys locally maybe additional encrypted. +Maybe it is possible to use Stronghold from iota for that. +With that the user don't need to use the Login-Server. \ No newline at end of file diff --git a/docu/Concepts/Snippets/Authorization/jwt.md b/docu/Concepts/Snippets/Authorization/jwt.md new file mode 100644 index 000000000..55355b2a5 --- /dev/null +++ b/docu/Concepts/Snippets/Authorization/jwt.md @@ -0,0 +1,20 @@ +# How JWT could be used for authorization with and without Login-Server +## What we need +The only encrypted data in db are the private key. +Every other data could be accessed without login, depending on frontend and backend code. +So we need only a way to prove the backend that we have access to the private key. + +## JWT +JWT is perfect for that. +We can use JWT to store the public key of the user as UUID for finding his data in db, +signing it with the private key. So even if the backend is running in multiple instances, +on every request is it possible to check the JWT token, that the signature is signed with +the private key, belonging to the public key. +The only thing the backend cannot do with that is signing a transaction. +That can only be done by the Login-Server or a Desktop or Handy-App storing the private key locally. +With that we have universal way for authorization against the backend. +We could additional store if we like to sign transactions local or with Login-Server and the Login-Server url. + + + + diff --git a/docu/Concepts/Snippets/Authorization/session_id.md b/docu/Concepts/Snippets/Authorization/session_id.md new file mode 100644 index 000000000..c8c64a87a --- /dev/null +++ b/docu/Concepts/Snippets/Authorization/session_id.md @@ -0,0 +1,16 @@ +# Session Id Authorization +## Login-Server +With every login, the Login-Server creates a session with a random id, +storing it in memory. For Login email and password are needed. +From email and an additional app-secret (**crypto.app_secret** in Login-Server config) a sha512 hash will be genereted, named **hash512_salt**. +With sodium function *crypto_pwhash* with **hash512_salt** and user password a secret encryption key will be calculated. +*crypto_pwhash* uses argon2 algorithmus to have a CPU hard calculation. Currently it is configured for < 0.5s. +So it is harder to use brute-force attacks to guess the password. Even if someone gets hands on the data saved in db. + +With sodium function *crypto_shorthash* a hash will be calculated from the secret encryption key and server crypto key (**crypto.server_key** in Login-Server config, hex encoded, 16 Bytes, 32 Character hex encoded) +and compared against saved hash in db. If they identical user has successfull logged in. +The secret encryption key will be stored in memory together with the user session and client ip from which login call came. +The session_id will be returned. +The session will be hold in memory for 15 minutes default, can be changed in Login-Server config field **session.timeout** + +