One of the most commonly implemented feature in APIs. It is a process of confirming the user's identification, such as checking the user's ID and password during login.
One-way hash functions create a digest (an encrypted message) from an original string message, which cannot be decrypted from the digest form.
Examples are MD5, SHA-1, SHA-256, SHA-512
import hashlib
m = hashlib.sha256()
m.update(b"test password")
m.hexdigest()
>>> '0b47c69b1033498d5f33f5f7d97bb6a3126134751629f4d0185c115db44c094e'
m = hashlib.sha256()
m.update(b"test password2")
m.hexdigest()
>>> 'd34b32af5c7bc7f54153e2fdddf251550e7011e846b465e64207e8ccda4c1aeb'
As we can see from the example above, similar original messages result in completely different digests. This characteristic of one-way hashing is known as "avalance," and it makes hacking the original messages difficult.
It is a library that has implemented salting and key stretching solutions to any attaks on user information, namely rainbow table attack. Rainbow table is a table of various pre-computed hash values, and the attack compares these values with the target password and evaluates if there is a match.
An advantage of using bcrypt is that the values for salt, hash, and the number of stretches are stored together in the hash result. This feature simplifies database architecture as there is no need to store those values separately and retrieve them later for authentication comparison.
비밀번호와 임의로 생성한 문자열(Salt)를 합쳐서 해싱하여 이 해시값을 저장하는 방법.
이 경우에는 비교를 위해 해시값과 Salt값을 같이 저장해야 함.
단방향 해쉬값을 계산 한 후 그 해쉬값을 또 또 해쉬 하고, 또 이를 반복하는 것을 말한다.
For more security measures, HTTPS protocol is used, which is a more secure version of HTTP. Using SSL certificate, requests and responses are encrypted and cannot be easily hijacked mid-communication.
The function of specifying access rights and privileges to resources (eg whether a logged-in user has access to certain information).
Authorization is done via encrypted access tokens that get included in the request header as meta data.
The tokens are decrypted by the server to acquire user information.
Common way of creating an access token is by using JSON Web Tokens. User data is stored in encrypted JSON format.
Authorization Steps
1. Authentication 절차를 통해 access token을 생성한다. access token에는 유저 정보를 확인할 수 있는 정보가 들어가 있어야 한다 (예를 들어 user id).
2. 유저가 request를 보낼때 access token을 첨부해서 보낸다.
3. 서버에서는 유저가 보낸 access token을 복호화 한다.
4. 복호화된 데이터를 통해 user id를 얻는다.
5. user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인하다.
6. 유저가 충분한 권한을 가지고 있으면 해당 요청을 처리한다.
7. 유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보낸다.
Header contains information about token type and hash algorithm.
Header's content is encoded in Base64 and recorded in the first section of JWT.
For example,
{
"alg":"HS256",
"typ":"JWT"
}
Payload contains statements about the entity (typically, the user) and additional entity attributes, which are called claims. Also encoded in Base64.
For example,
{
"sub": "12345678",
"name": "John Doe",
"admin": true
}
Signature is the only part of JWT that is actually encrypted. It is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way.
The signature is created by taking Base64-encoded header, payload, and a secret along with a hashing algorithm such as SHA256.
If you are to create a signature for a token, you would need to do the following:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
Unlike digests produced using bcrypt, JWTs can be and should be reversed, as they are used to constantly check for authorization for each user.
Performance
No heavy bcrypt call, just a simple hash
Client-side storage
Actual ID and password are not stored in the client side (ex-cookie).
Token is very server specific and cannot be reused in any other site, which provides more stable and secure means of authorization.