OpenID là gì, cách hoạt động của OpenID

I.

GIỚI THIỆU

Bạn đã bao giờ thấy một trang đăng nhập bằng Facebook hay
Google giống như vậy nhưng mà trang đó không có mối liên hệ gì
tới chúng?

Có thể nó đã sử dụng OpenID hoặc OAuth2 để cho phép bạn đăng
nhập vào bằng tài khoản MXH. Tôi sẽ giải thích cách nó hoạt động
một cách đơn giản nhất.

II.

XÁC THỰC TRUYỀN THỐNG

Trước khi vào chủ đề chính, chúng ta cùng tìm hiểu một chút về
khái niệm xác thực truyền thống. Hầu hết các hệ thống chúng ta
được biết được xây dựng theo cách này.


Xác thực truyền thống
Người dùng sử dụng trình duyệt truy cập vào 1 website, nếu trang
web yêu cầu xác thực bằng cách nhập username và password
được xác minh trong database người dùng. Database này là một
phần của hệ thống, nó đơn giản và hoạt động tốt, nhưng từ góc
nhìn của người dùng thì có rất nhiều website và mỗi website họ
phải có một tài khoản riêng liên kết tới database của trang web
đó. Từ lý do bảo mật mà người dùng phải sử dụng password khác
nhau cho từng trang và thay đổi chúng thường xuyên.

Có rất nhiều website nên user phải dùng một tài
khoản riêng biệt cho mỗi website


Việc này khá là bất tiện, sẽ tiện lợi hơn nếu tất cả các website
này dùng cung một cơ sở dữ liệu người dùng. Người dùng sẽ chỉ
cần có một tài khoản đăng nhập cho tất cả. Nhưng một trang web
này không được quyền truy cập vào bất kỳ trang web nào khác
bằng quyền sử dụng thông tin người dùng. Tôi sẽ không muốn
Twitter đọc email của tôi trong Gmail, nhưng thật tuyệt nếu tôi có
thể sử dụng cùng một tài khoản để truy cập cả hai ứng dụng. May
mắn là có một cách làm được điều đó.

Sẽ tiện lợi hơn nếu nhiều website dùng chung một
database

III.

OPENID LÀ GÌ

OpenID là một giao thức tiêu chuẩn mở và tập trung, được phát
triển bởi tổ chức phi lợi nhuận OpenID Foundation.


Một người dùng có một tài khoản OpenID thông qua một nhà
cung cấp nhận dạng (OpenID identity provider) chẳng hạn như
Google, Facebook, … Người dùng sử dụng tài khoản này để đăng
nhập vào bất kỳ website (relying party) chấp nhận xác thực bằng
OpenID (giống như YouTube chấp nhận sử dụng một tài khoản
Google để đăng nhập). Người dùng có thể tùy chọn nhà cung cấp

OpenID vì chủ trang web đã cấu hình cho phép làm điều này. Điều
quan trọng là mật khẩu người dùng không được gửi cho website
(relying party) khi đang xác thực trên nhà cung cấp OpenID.

IV.

CÁCH OPENID HOẠT ĐỘNG

1. Các khái niệm
- The OpenID Identifier: Một chuỗi xác định và duy nhất cho
một người dùng.
-

The OpenID Relying Party (RP): Một nguồn tài nguyên
trực tuyến (có thể là một trang web, nhưng nó có thể là một
tập tin, hình ảnh, hoặc bất cứ điều gì bạn muốn kiểm soát


quyền truy cập vào) có sử dụng OpenID để xác định những
người có thể truy cập nó.

-

The OpenID Provider (OP): Một trang web mà người sử
dụng có thể yêu cầu một OpenID và sau đó đăng nhập và
xác thực danh tính để truy cập RP (có thể gặp nhiều OP quen
thuộc như Facebook, Google, Twitter, …).

2. OpenID hoạt động như thế nào?
OpenID có 2 mode: Dumb và Smart

a. Dumb mode:

End User nhận được một form yêu cầu đăng nhập bằng
OpenID
2. User Agent phản hồi cho Consumer một URL đại diện cho
OpenID của họ (VD: />3. Consumer hợp thức hóa URL OpenID và sử dụng phiên bản
chính tắc để gửi request (GET) một tài liệu từ OpenID Server.
4. OpenID Server trả về một tài liệu HTML (OpenID version 1.0)
hoặc tài liệu Yadis (OpenID version 2.0)
1.


5.

-

-

-

6.
7.
8.
9.
10.
-

-

-

-

Consumer tìm trong tài liệu này một liên kết tới OpenID
Server, sau đó chuyển hướng User Agent đến đó và cung cấp
thêm vài tham số bổ sung:
openid.mode = checkid_setup : chọn mode dumb, mode này
có nghĩa là Consumer sẽ chuyển hướng User Agent đến
OpenID Server để kiểm tra danh tính của End User. OpenID
Server sẽ trả lời cho Consumer thông qua User Agent sau khi
kiểm tra xong.
openid.identity = : đây là
danh tính cung cấp bởi End User và OpenID Server phải xác
minh danh tính này cho Consumer.
openid.return_to = />session_id=User&nonce=123456 : Đây là nơi Consumer
muốn User Agent đến sau khi OpenID Server xác thực xong.
OpenID Server cũng sẽ thêm vài tham số bổ sung để xác
thực người đang trả lời cho Consumer chính là OpenID.
OpenID Server gửi về màn hình đăng nhập cho User.
User gửi ID và mật khẩu đến OpenID Server (phương thức
POST).
OpenID Server gửi về một form trust hỏi User có muốn tin
tưởng cho Consumer dùng danh tính của anh ta.
User Agent POST phản hồi cho OpenID Server (chấp nhận
hoặc không chấp nhận).
OpenID Server chuyển hướng User Agent đến Consumer.
Cung cấp thêm vài thông số sau:
openid.mode = id_res : Giá trị “id_res” chỉ ra rằng OpenID
Server khẳng định End User thực sự sở hữu danh tính này.
Nó sẽ là “cancel” nếu End User không chấp nhận tin tưởng

Consumer.
openid.return_to = />session_id=User&nonce=123456 : trang thông báo trạng
đăng nhập thành công hay thất bại, nơi mà User Agent sẽ
được chuyển đến sau khi xác thực xong.
openid.signed = mode,identity,return_to : những thông số
mà OpenID Server sẽ “ký” để chứng minh cho Consumer đây
đích thực là OpenID Server của End User.
openid.assoc_handle = *opaque handle* : bộ xử lý mã hóa
của OpenID Server, tạo ra một khóa để dùng cho openid.sig.
openid.sig = *base 64 encoded HMAC signature*: các thông
số mode, identity, return_to được OpenID Server mã hóa
bằng thuật toán tạo chữ ký HMAC-SHA1 dùng khóa từ bộ xử


11.

12.

13.
•

lý mã hóa ở trên. Nhằm mục đích “ký” các thông số này rồi
gửi đến Consumer.
Sau khi OpenID chuyển hướng User Agent đến Consumer và
gửi kèm thêm các thông số bổ sung để xác nhận danh tính
End User và danh tính của mình bằng cách ký các thông số
đó. Nhưng Consumer không thể tự mình kiểm tra cái “chữ
ký” này và các thông số này đều đến từ End User, có thể nó
đã được hacker chỉnh sửa nhằm xâm nhập vào tài khoản của
End User. Vì vậy Consumer lại chuyển công việc lại cho

OpenID Server, Consumer POST đến OpenID Server rồi gửi
các thông số:
openid.mode = check_authentication: mode này muốn hỏi
OpenID Server liệu đây có đúng là End User không.
openid.signed = mode,identity,return_to: các thông số mà
User bảo OpenID Server đã ký.
openid.assoc_handle = *opaque handle*: bộ xử lý mà User
đã gửi cho Consumer
openid.sig = *base 64 encoded HMAC signature*: “chữ ký”
của OpenID Server xác nhận đây chính là End User.
openid.* = everything else: những thông số đã “ký” (trừ
mode)
Khi OpenID Server nhận được yêu cầu này, nó lấy chữ ký từ
các thông số đã ký trước đó so sánh với các thông số nhận
được từ Consumer. Nếu khớp nhau, OpenID Server biết là
đây chính là những tham số mà mình đã ký và gửi một thông
báo cho cho Consumer biết thông tin này hợp lệ: "is_valid:
true". Nếu chữ ký không hợp lệ thì OpenID Server trả về
thông báo "is_valid: false" và Consumer biết được là có kẻ
đang cố tình giả mạo End User.
Consumer gửi cho End User một trang thông báo đăng nhập
thành công hay thất bại, dựa vào kết quả của các bước trên.
Trong trường hợp Consumer không yêu cầu OpenID Server
tương tác với End User, trong tham số gửi đi ở bước 5,
“openid.mode” sẽ là “checkid_immediate”. Điều này cho
phép User Agent bật lên một cửa sổ web mới "openid.user \
_setup \ _url" để End User xác thực với OpenID Server bằng
cách đăng nhập, sau đó gửi kết quả xác thực về cho
Consumer trên phiên làm việc của cửa sổ này thay vì phải
chuyển hướng User Agent. Việc này giúp trải nghiệm của

End User trên trang web mượt mà, không bị ngắt quãng.


b. Smart mode:
Ở dumb mode, mỗi lần End User cần xác thực, OpenID Server gửi
cho Consumer các tham số để xác thực End User và chứng minh
OpenID Server là “chính chủ” thông qua User Agent (ở bước 10).
Do Consumer không thể xử lý các thông số này vì nó đã được bộ
xử lý của OpenID Server mã hóa, nên Consumer phải trực tiếp gửi
lại các tham số này cho OpenID Server để xác nhận lại chúng.
Việc nay làm tốn khá nhiều CPU của cả OpenID Server và
Consumer. Nếu Consumer và OpenID Server cùng chia sẻ bộ xử lý
mã hóa này thì cả hai sẽ đỡ tốn rất nhiều tài nguyên.


Đó là smart mode, Consumer thiết lập một bộ xử lý mã hóa dùng
chung với OpenID Server. Việc chia sẻ thiết lập này được thực hiện
bất kỳ lúc nào, không nhất thiết phải chờ End User cần xác thực
mới thiết lập (trong ví dụ này chúng sẽ thiết lập ở bước 5).
Consumer sẽ gửi một request POST tới OpenID Server để tiến
hành thiết lập:
-

-

-

openid.mode = associate: mode associate, có nghĩa là
Consumer muốn thiết lập một bộ mã hóa dùng chung với
OpenID Server.

openid.assoc_type = HMAC-SHA1: loại mã hóa mà Consumer
muốn chia sẻ, ở đây OpenID chỉ hỗ trợ HMAC-SHA1.
openid.session_type = DH-SHA1: loại phiên mà bộ xử lý sẽ
được chia sẻ, ở đây dùng giao thức trao đổi khóa DiffieHellman.
openid.dh_* = *meh*: một vài tham số để hỗ trợ giao thức
trao đổi khóa nếu Diffie-Hellman được sử dụng.

Khi Consumer gửi request này tới OpenID Server (bước 6), OpenID
Server tạo một khóa bằng bộ xử lý khóa assoc_\handle như dumb
mode. Nhưng nó có thể lưu giữ trạng thái (stateful) thay vì phi
trạng thái (stateless) như dumb mode. OpenID Server sau đó trả
lời cho Consumer một số tham số để lưu trữ trạng thái này. Hai
tham số trong đó là *assoc\_handle* và *mac\_key* (hoặc
*enc\_mac\_key* nếu Diffie-Hellman được sử dụng) giúp Consumer


có thể hiểu được và xác minh yêu cầu xác thực của OpenID Server
mà không cần phải gửi lại.
Các bước còn lại được trình bày giống như dumb mode, tùy theo
mode checkid_\setup hay checkid_\immediate, nhưng khác ở chỗ
khi Consumer nhận được yêu cầu xác thực từ OpenID Server
thông qua User Agent (bước 12), nó sẽ tự hiểu và xác thực thông
tin này mà không cần gửi lại cho OpenID Server để xác thực, vì
Consumer đã lưu trữ bộ xử lý mã hóa dùng chung với OpenID
Server. Và cuối cùng, Consumer gửi về thông điệp cho User Agent
thông báo việc xác thực thành công hay thất bại (bước 13).

V.

VẤN ĐỀ BẢO MẬT

1. Lỗi xác thực
Do RP chỉ nhận được yêu cầu xác thực của OP thông qua
trình duyệt của user, kẻ tấn công có thể giả mạo yêu cầu
OpenID mà không yêu cầu địa chỉ email của người dùng và
sau đó chèn địa chỉ email của hắn vào phản hồi của OP. Nếu
kẻ tấn công gửi phản hồi này đến trang web không để ý
tham số không được OP ký, trang web có thể bị lừa đăng
nhập kẻ tấn công vào bất kỳ tài khoản cục bộ nào.


2. Pishing

OpenID có điểm yếu về bảo mật và dễ bị tấn công pishing. Ví
dụ: một RP độc hại có thể chuyển tiếp người dùng đến trang
OP của google giả mạo yêu cầu người dùng đó nhập thông
tin đăng nhập của họ. Sau khi hoàn thành việc này, RP độc
hại (trong trường hợp này cũng kiểm soát trang OP giả mạo)
sau đó có thể có quyền truy cập vào tài khoản google của
người dùng, sau đó sử dụng tài khoản đó của người dùng để
đăng nhập vào các dịch vụ khác.


3. Xác thực chiếm quyền điều khiển trong kết nối không bảo
mật

Một lỗ hổng quan trọng khác xuất hiện ở bước cuối cùng
trong sơ đồ xác thực khi TLS / SSL không được sử dụng: URL
chuyển hướng từ OP đến RP. Vấn đề với chuyển hướng này là
thực tế là bất kỳ ai có thể lấy URL này (ví dụ: bằng cách bắt

gói) có thể lặp lại nó và đăng nhập vào trang web với tư
cách là người dùng nạn nhân. Một số OP sử dụng nonces (số
được sử dụng một lần) để cho phép người dùng chỉ đăng
nhập vào trang web một lần. Giải pháp nonce hoạt động nếu
người dùng là người đầu tiên sử dụng URL. Tuy nhiên, kẻ tấn
công bắt gói rất nhanh có thể lấy URL và ngay lập tức thiết
lập lại kết nối TCP của người dùng (vì kẻ tấn công đang bắt
gói và biết các số thứ tự TCP cần thiết) và sau đó thực hiện
tấn công phát lại như mô tả ở trên. Do đó, nonces chỉ bảo vệ
chống lại những kẻ tấn công thụ động, nhưng không thể
ngăn chặn những kẻ tấn công chủ động thực hiện cuộc tấn


công chơi lại. Việc sử dụng TLS / SSL trong quá trình xác thực
có thể giảm đáng kể rủi ro này.
4. Chuyển hướng bí mật

Chuyển hướng bí mật là một lỗ hổng bảo mật cho phép kẻ
tấn công khai thác lỗ hổng Chuyển hướng mở.
Chuyển hướng mở có một lỗ hổng khi kiểm tra xem URL
chuyển hướng có phải là một URL hợp lệ không. Kẻ tấn công
Chuyển hướng bí mật lợi dụng điểm yếu đó để bật lên cửa sổ
đăng nhập lừa đảo, sau đó đánh cắp thông tin đăng nhập và
chuyển hướng người dùng đến trang cài đặt phần mềm độc
hại cho nhiều mục đích hơn, chẳng hạn như trộm danh tính.