Properties of Hashing
Salt is a cryptographically secure random string that is added to a password
before it’s hashed, and the salt should be stored with the hash, making it difficult
for an attacker to know the original plaintext without having access to both
sources.
Why do we use salt?
There is a database which has most of the password hash so we can find the
password using hash matching. So we have to add salt before hashing password
It is also called block cipher Encryption because it encrypted the data block by
block
JWT TOKEN
With JWT, the possession and the use of the key materials are exactly the same
as any other contexts where cypher operations occur.
For signing:
● The private key is owned by the issuer and is used to compute the
signature.
● The public key can be shared with all parties that need to verify the
signature.
For encryption:
● The private key is owned by the recipient and is used to decrypt the data.
● The public key can be shared to any party that want to send sensitive data
to the recipient.
The encryption is rarely used with JWT. Most of the time the HTTPS layer is
sufficient and the token itself only contain a few information that are not sensitive
(datatime, IDs...).
The issuer of the token (the authentication server) has a private key to generate
signed tokens (JWS). These tokens are sent to the clients (an API server, a
web/native application...). The clients can verify the token with the public key.
The key is usually fetched using a public URI.
If you have sensitive data that shall not be disclosed to a third party (phone
numbers, personnal address...), then the encrypted tokens (JWE) is highly
recommended. In this case, each client (i.e. recipient of a token) shall have a
private key and the issuer of the token must encrypt the token using the public
key of each recipient. This means that the issuer of the token can select the
appropriate key for a given client.
Ssl certificate working
Browser connects to a web server (website) secured with SSL (https). Browser
requests that the server identify itself.
Server sends a copy of its SSL Certificate, including the server’s public key.
Browser checks the certificate root against a list of trusted CAs and that the
certificate is unexpired, unrevoked, and that its common name is valid for the
website that it is connecting to. If the browser trusts the certificate, it creates,
encrypts, and sends back a symmetric session key using the server’s public key.
Server decrypts the symmetric session key using its private key and sends back
an acknowledgement encrypted with the session key to start the encrypted
session.
Server and Browser now encrypt all transmitted data with the session key.
How does the browser check the certificate root against a list of trusted
CAs?
Server sends the ssl certificate to the browser. Ssl certificate is generated by CA
which is digitally signed(digital signature) with its private key(CA private key) and
browsers have most of the CA public key (installed on browser) and public key is
used to verify the signature. It verifies the CA, and CA generates ssl certificates
only for authenticating organizations. Through this way browsers check the ssl
certificate for the server or organization.
