1. Login Authentication
Login is the process of verifying a user’s identity. It consists of two main components: identification and authentication.
Identification:
Identification refers to locating specific data among a large set of information. Identifying information must be unique and non-duplicable, such as a user ID, phone number, or email address.
In databases, these are typically used as primary keys, which must not be duplicated under any circumstances.
Even if identifying information is public, it usually doesn't pose a direct security risk. However, personally identifiable information (PII) is considered more sensitive and dangerous when exposed.
-
Personally Identifiable Information (PII): Data that can be used to uniquely identify an individual, such as resident registration numbers, driver's license numbers, or passport numbers.
Authentication:
Authentication is the process of verifying that the person is truly who they claim to be. Login is a common form of authentication.
It usually involves credentials, such as a password, but can also include OTP (One-Time Passwords), and must be securely stored in the database (e.g., hashed and salted).
In summary:
Login involves both identification (who you are) and authentication (proving it’s really you).
You must provide both an identifier and authentication credentials together.
2. Login Logic Case
1) Performing Identification and Authentication Simultaneously
This approach performs both identification and authentication in a single step.
It implements login by executing one SQL query that checks both the identifier and the credentials at the same time.
Example: Logging in by querying the database once using both the username (or email/phone number) and password.
Putting both the ID and password into a single SELECT
statement.
This method compares the ID with the database, and simultaneously checks the password.
If both conditions are satisfied, the login is successfully executed.
In other words, the login query validates both the user ID and the password in one step.
If the user ID is "normaltic" and the password is "1234", a matching user record will be returned.
If either the ID or the password is incorrect, no results will be returned.
In this approach, if a result is returned from the query, the login is considered successful.
If no result is returned, the login is treated as failed.
2) Performing Identification and Authentication Separately
This method separates identification (ID) and authentication (password) into two steps.
First, the system retrieves the password from the database using the provided ID and stores it in a variable such as db_pass
.
Then, it compares the user’s input password with the password stored in the database.
An if
statement is used to determine whether the login is successful or not, based on the result of the comparison.
Hashing is a one-way function, meaning the original value cannot be restored from the hash.
It is different from encryption or encoding, and unlike encryption, it is not reversible (no decryption).
Even if a hash is exposed, it is generally safe — at least for a single use — because the original value cannot be recovered from it.
Since hashing produces a consistent and deterministic result, it can always be used for comparison.
Although we can’t know what password a user entered, we can still verify whether it’s correct, by comparing the hash values.
The hash value itself does not change, as long as the input remains the same.
3) Performing Identification and Authentication Simultaneously (Hashing)
4) Performing Identification and Authentication Separately (Hashing)
3. Login Persistence
1) In the early days of the web, login persistence was handled using cookies.
The Set-Cookie header would store both the user ID and password, and the browser would automatically include these cookie values with every request.
However, the origin of the request is the client — and since attackers are also clients,
they can manipulate cookie values freely.
This means that if sensitive information like user IDs and passwords are stored in cookies, it becomes vulnerable to tampering or misuse by malicious users.
A user could modify cookies to log in as a different user.
The main issue was that cookies are stored on the client side, which means the user can freely edit or manipulate them.
2) The Introduction of Sessions
Sessions were introduced as a more secure method.
With sessions, login information is stored on the server side, not on the client.
This approach makes it much harder for users or attackers to manipulate authentication data, since it is not accessible or editable from the client side.
They try to steal the session ID.
If you inspect the cookies, you can often find the session ID stored there.
In fact, some past account hacking incidents on platforms like Naver and YouTube involved session hijacking — where the attacker used a stolen session ID to impersonate a user.
To enhance security, the session ID changes every time you log in.
So even if a session ID is stolen, it becomes useless as soon as the user logs in again or logs out.
However, in poorly implemented systems, the session might not be invalidated properly on logout, which can leave the session vulnerable.
3) JWT(JSON Web Token)
What is JWT?
-
A digital token issued after login
-
Enables stateless authentication (no session saved on the server)
How it works
-
Server issues a JWT upon successful login
-
Client stores the token (in localStorage or cookies)
-
Client sends the token with each request (
Authorization
header) -
Server verifies the token to authenticate
Pros
-
No need to store sessions on the server
-
Scales well for distributed systems
Cons
-
Risky if exposed → Use HTTPS
-
Logout is harder to manage (token expiration needed)
4. Assignment
1) Review today's lesson
2) Work on any unfinished assignments
3) Create a login page (4 logic patterns):
-
Identification & authentication combined
-
Identification & authentication separated
-
Combined (with password hashing)
-
Separated (with password hashing)
password_hash()
in my code, but due to difficulties in performing identification and authentication simultaneously, I switched to SHA-256 for hashing.
댓글 없음:
댓글 쓰기