Skip to content

Authentication

인증(認證, authentication)은 참이라는 근거가 있는 무언가를 확인하거나 확증하는 행위이다. 객체를 인증하는 것은 이에 대한 출처를 확인하는 것을 뜻하는 반면, 사람을 인증하는 것은 사람들의 신분을 구성하는 것을 말한다. 인증은 하나 이상의 인증 요인에 따라 달라질 수 있다.

Categories

Projects

Identity and Access Management Servers

Access Control

Libraries

Secret Management

쉽게 알아보는 서버 인증

서버/클라이언트 사이 인증 및 패스워드 저장 방법

First, make sure you read this answer to the question "Client side password hashing", paying particular attention to the last paragraph.

Also, please realize that client side javascript is going to be incredibly slow at PBKDF2 compared to good server side code. At least try to find a PBKDF2 implementation that uses HMAC-SHA-512 as a base.

That said, if you want to give the user peace of mind, that's fine; do the following:

  • Client side PBKDF2 hashing for a known, "high" iteration count.
    • Double bonus points if the user is allowed to select the iteration count themselves!
    • I put high in quotes because I doubt your javascript code's going to be fast enough to do tens or hundreds of thousands of iterations in the time you can get enough of your user base to accept, particularly on cheaper mobile devices.
    • A good hash of the username and password as a salt isn't great, though it's better if your code pads the username out to the maximum possible length and puts it first.
      • That way, "user1" and "password" don't make the same salt as "user" and "1password"!
      • There is, of course, no maximum length on the password except what's caused by your back end software; SQL Server, for instance, has an 8000 byte maximum on "less inefficient" string work.
  • Send that hash by itself to the server
    • which then DOES generate a cryptographically random salt of 12-16 bytes
    • and then uses PBKDF2 with a much higher iteration count to hash the hash passed in
      • again hopefully HMAC-SHA-512 for the 64 bit operations to lessen the proportionate advantage of offline GPU attacks.
      • because then someone who gets your leaked password database still has to do the work of an attack against a password hashing function to log in, rather than simply sending the client-generated hash they stole and having it be accepted as-is.

Remember with PBKDF2 password hashing in particular, never ask for an output size larger than the native base hash's output size. Smaller is all right if you're really, really concerned about storage; for instance, requesting only 32 bytes of PBKDF2-HMAC-SHA-512's native 64 byte output.

  • 20 bytes for SHA-1
  • 32 bytes for SHA-256
  • 64 bytes for SHA-512

Client side password hashing

Hashing on the client side doesn't solve the main problem password hashing is intended to solve - what happens if an attacker gains access to the hashed passwords database. Since the (hashed) passwords sent by the clients are stored as-is in the database, such an attacker can impersonate all users by sending the server the hashed passwords from the database as-is.

On the other hand, hashing on the client side is nice in that it ensures the user that the server has no knowledge of the password - which is useful if the user uses the same password for multiple services (as most users do).

A possible solution for this is hashing both on the client side and on the server side. You can still offload the heavy PBKDF2 operation to the client and do a single hash operation (on the client side PBKDF2 hashed password) on the server side. The PBKDF2 in the client will prevent dictionary attacks and the single hash operation on the server side will prevent using the hashed passwords from a stolen database as is.

See also

Favorite site

References

  1. Server_authentication_made_easy_1.pdf ↩

  2. Server_authentication_made_easy_2.pdf ↩

  3. Server_authentication_made_easy_3.pdf ↩

  4. NAVER_D2_-_Secure_password_storage.pdf ↩