根據 [RFC 5321] 定義:
Email @ 後面的 Domain name 最大長度是 255
@ 前面的 local-part (也就是只有 Account ID 的部分, 不含 @ 之後) 最大長度是 64
由於大部分的人, 通常會拿 Email 的 ID 部分當作帳號名稱,
所以最大長度給 64 應該足夠大部分情境使用.
其實我比較在意的是最小的長度限制，例如只有一個字也OK嗎?帳號只有一個字會有問題嗎?
長度太短會提高資安風險, 容易被 Brute Force 手段猜中...
黑客猜密碼之前, 要先知道明確的帳號 ID, 才能據此測試; 如果對方連 ID 都不知道 (或短時間內猜不到), 那他就要先花一段時間, 或者花一些成本, 先取得 ID 的清單 (或特定的目標), 之後, 才可以開始猜密碼工作.
資安防禦講求的是縱深, 在被攻破的這段路程上, 我們盡可能部署更多的阻礙, 讓他無法長驅直入, 一路遇到挫折. 所以: 難猜到的 ID, 可以是一種障礙.
如果 ID 很短, 例如只有一個字元, 那麼他猜的範圍就縮短許多, 可能只剩下:
0-9, A-Z, a-z 這些而已, 總數還不到一百個.
這樣他要一個一個去做測試, 就變得很容易而且時間很短, 而我們也可能還來不及觸發防禦措施, 就已經被他猜中了.
但是如果限制 ID 至少要 8 個字元以上的話, 那它至少要從這裡開始猜:
00000000
00000001
00000002
00000003
00000004
.
.
.
0000000z
如果我的 ID 是 abX8590s, 他要猜多久才會中?
對她來說, 猜的範圍擴大到一千萬倍, 猜中 ID 的成本也跟著提高. 他得先猜中 ID 之後, 才能開始猜密碼, 又要乘上幾千萬或者幾億次的成本.
在設計資安縱深的時候, 還有一個原則:
我們要盡量增加攻擊者的成本, 但是也要減輕使用者的成本.
限制 ID 最短長度這件事情, 可以大幅增加攻擊成本; 但確實也會增加一點點使用者成本: 有些使用者可能記不住太長的 ID.
所以, 我們要在兩者之間取得平衡, 通常最短 6 個字元以上還算可被接受; 嚴格一點的可以用 8 字元; 高機敏高風險單位可能會要求到 12 字元.
raytracy 您從資安的觀點解釋帳號的長度，我完全懂了，感謝!!
這倒沒有慣用長度。
我只能將我的習慣給你
一般email來說。我常用的長度為50
而非email的帳號來說。一般我會預設15~20長度。
(視帳號生成情況而定)
若是要設計一個可讓使用者登入的網站系統時，使用者帳號不使用 email，而是讓使用者自己輸入一個不和其他人重複的帳號。這樣的帳號一般會有一定的長度限制。限制長度的原因是為了讓帳號更安全、易於記憶和確保唯一性。一般來說，若要符合上述的帳號長度通常建議在8到20個字符之間。在設計時，需要考慮這些因素，平衡它們並根據實際情況進行設計。
iThome鐵人賽
看影片追技術