Session cookies for web applications [http://lwn.net/Articles/283383/]
By Jake Edge
May 21, 2008
Two weeks ago on this page, we reported on some Wordpress vulnerabilities that were caused by incorrectly generating authentication cookies. The article was a bit light on details about such cookies, so this follow-up hopes to remedy that. In addition, Steven Murdoch, who discovered both of the holes, recently presented a paper on a new cookie technique that provides some additional safeguards over other schemes.
兩周前在此頁上，我們報道了由不正確生成的身份驗證 cookies 引起的一些 Wordpress 漏洞。那篇文檔對這些 cookies 的細節描述略少，這篇后續的文章希望能解決這個問題。另外，發現這些漏洞的 Steven Murdoch，最近發表了篇關于一種新的 cookie 技術的文章，文章提供了其他方案之`上`的一些額外保護措施。
HTTP is a stateless protocol which means that any application that wishes to track multiple requests as a single session must provide its own way to link those requests. This is typically done through cookies, which are opaque blobs of data that are stored by browsers. Cookies are sent to the browser as part of an HTTP response, usually after some kind of authentication is successful. The browser associates the cookie with the URL of the site so that it can send the cookie value back to the server on each subsequent request.
HTTP 是一種無狀態的協議，這意味著任何希望跟蹤多個請求作為單個會話的應用程序，必須提供自己的方式來鏈接這些請求。這通常通過 cookies 來完成，cookies 是瀏覽器存儲的不透明的數據塊。通常，在某種身份認證成功后，cookies 被作為一個 HTTP 響應的一部分發送給瀏覽器。瀏覽器把 cookie 和對應網站的 URL 關聯起來，以便它可以在每個后續請求中回送 cookie 值到服務器。
Servers can then use the value as a key into some kind of persistent storage so that all requests that contain that cookie value are treated as belonging to a particular session. In particular, it represents that the user associated with that session has correctly authenticated. The cookie lasts until it expires or is deleted by the user. When that happens, the user must re-authenticate to get a new cookie which also starts a new session. Users find this annoying if it happens too frequently, so expirations are often quite long.
然后，服務器可以`用某種持久性存儲的鍵`使用該值，使得所有包含該 cookie 值的請求，被視為屬于同一個特定會話。特別是，它代表和該會話關聯的那個已經正確通過身份驗證的用戶。一個 cookie 一直存在，直到過期或被用戶刪除。此時，用戶必須重新進行身份驗證，獲取一個新 cookie，同時開始一個新會話。如果它發生的過于頻繁，會讓用戶感到惱人，所以到期時間通常相當長。
If the user explicitly logs out of the application, any server-side resources that are being used to store state information can be freed, but that is often not the case. Users will generally just close their browser (or tab) while still being logged in. It is also convenient for users to be allowed multiple concurrent sessions, generally from multiple computers, which will cause the number of sessions stored to be larger, perhaps much larger, than the number of users.
如果用戶顯式地登出應用程序，任何用來存儲狀態信息的服務器端資源會被釋放，但情況經常不是這樣。用戶通常只是關閉他們的瀏覽器（或標簽頁），當仍在登錄狀態時。這也允許用戶方便地，從不同的計算機上使用多個并發會話。這將導致存儲更大的會話數量，也許比用戶數量大許多。
Applications could restrict the number of sessions allowed by a user, or ratchet the expiration value way down, but they typically do not for user convenience. This allows for a potential denial of service when an attacker creates so many sessions that the server runs out of persistent storage. For this reason, stateless session cookies [PDF][http://prisms.cs.umass.edu/~kevinfu/papers/webauth_tr.pdf] were created.
應用程序可以限制允許一個用戶使用的會話數，或者``，但它們通常不方便用戶使用。這允許一個潛在的拒絕服務，當一個攻擊者創建太多會話，以至于服務器用完持久性存儲時。出于這個原因，無狀態會話 cookies 被創建。
Stateless session cookies store all of the state information in the cookie itself, so that the server need not keep anything in the database, filesystem, or memory. The data in the cookie must be encoded in such a way that they cannot be forged, otherwise attackers could create cookies that allow them access they should not have. This is essentially where Wordpress went wrong. By not implementing stateless session cookies correctly, a valid cookie for one user could be modified into a valid cookie for a different user.
無狀態會話 cookies 把所有狀態信息存儲到 cookie 本身，使服務器不需要在數據庫、文件系統或內存中保存任何信息。Cookie 中的數據必須以不能被偽造的方式編碼，否則攻擊者可以創建允許他們訪問不應該訪問內容的 cookies 。實際上這就是 Wordpress 出問題的地方。由于沒有正確使用無狀態會話 cookies ，一個用戶的有效 cookie 可以被修改成另一個不同用戶的有效 cookie 。
A stateless session cookie has the state data and expiration "in the clear" followed by a secure hash (SHA-256 for example) of those same values along with a key known only by the server. When the server receives the cookie value, it can calculate the hash and if it matches, proceed to use the state information. Because the secret is not known, an attacker cannot create their own cookies with values of their choosing.
一個無狀態的會話 cookie 有狀態數據和明確的到期時間，后跟一個安全哈希值（例如 SHA-256），該哈希值和只有服務器知道的一個鍵`對應`。當服務器接收到 cookie 值，會計算哈希值，如果匹配，繼續使用其中的狀態信息。由于這個密鑰是未知的，攻擊者不能使用他們選擇的值創建自己的 cookies 。
The other side of that coin is that an attacker can create spoofed cookies if they know the secret. Murdoch wanted to extend the concept such that even getting access to the secret, through a SQL injection or other web application flaw, would not feasibly allow an attacker to create a spoofed cookie. The result is hardened stateless session cookies [PDF][http://www.cl.cam.ac.uk/~sjm217/papers/protocols08cookies.pdf].
硬幣的另一面是，如果攻擊者知道密鑰，可以創建欺騙性的 cookies 。Murdoch 希望擴展概念，使得通過 SQL 注入或其它 web 應用漏洞訪問密鑰后，攻擊者也無法創建一個欺騙性的 cookie。結果就是強化的無狀態會話 cookies 。
The basic idea behind the scheme is to add an additional field to stateless session cookies that corresponds to an authenticator generated when an account is first set up. This authenticator is generated from the password at account creation by iteratively calculating the cryptographic hash of the password and a long salt value.
該方案背后的基本思路是，給無狀態會話 cookie 增加一個額外的字段，這個字段和賬戶首次設置時生成的一個`身份驗證器`對應。身份驗證器由創建賬戶時的密碼生成，生成方法是，迭代計算密碼的加密哈希和一個長 salt 值。
Salt is a random string—usually just a few characters long—that is added to a password before it gets hashed, then stored with the password in the clear. It is used to eliminate the use of rainbow tables to crack passwords. Hardened stateless session cookies use a 128-bit salt value, then repeatedly calculate HASH(prev|salt), where prev is the password the first time through and the hash value from the previous calculation on each subsequent iteration.
Salt 是一個隨機字符串——通常只有幾個字符長——它在被計算哈希值前添加到密碼中，然后以明文形式和密碼一起存儲。它是用來杜絕使用彩虹表破解密碼的。`硬化`的無狀態會話 cookies 使用128位 salt 值，然后迭代計算 HASH(prev|salt) ， 其中 prev 在第一次迭代時是密碼，在以后每次迭代中是上次計算的 hash 值。
The number of iterations is large, 256 for example, but not a secret. Once that value is calculated, it is hashed one last time, without the salt, and then stored in the user table as the authenticator. When the cookie value is created after a successful authentication, only the output of the iterative hash itself is placed in the cookie, not the authenticator that is stored in the database. Cookie verification then must do the standard stateless session cookie hash verification, to ensure that the values have not been manipulated, then hash the value in the cookie to verify against authenticator in the database.
迭代次數是個大的值，例如256，但這不是保密的。值被計算出來后，再不使用 salt 哈希一次，然后作為身份驗證器存儲到用戶表中。當 cookie 通過一次成功認證被創建后，只有輸出的迭代哈希值被保存在 cookie 中，而不保存數據庫中的身份驗證器。Cookie 驗證必須進行標準的無狀態會話 cookie 哈希驗證，來確保值沒有被修改過，然后哈希 cookie 中的值和數據庫中的身份驗證器對比。
If it sounds complicated, it is; the performance of doing 256 hashes is also an issue, but it does protect against the secret key being lost. Because an attacker cannot calculate a valid authenticator value to put in the cookie (doing so would require breaking SHA-256), they cannot create their own spoofed cookies.
如果這聽起來很復雜，確實；進行256次哈希的性能也是一個問題，但它確實能避免密鑰丟失。因為攻擊者無法計算一個有效的用戶驗證器放進 cookie 中（這樣做需要突破 SHA-256），所以他們不能創建自己的欺騙 cookie 。
While it is not clear that the overhead of all of these hash calculations is warranted, it is an interesting extension to the stateless session cookie scheme. In his paper, Murdoch mentions some variations that could be used to further increase the security of the technique.
目前尚不清楚所有這些哈希計算的開銷是否有必要，這是一個擴展無狀態會話 cookie 的有趣方案。在他的文章中，Murdoch 提到了一些可以進一步提高該技術安全性的變化。
---
后面沒看明白。
無狀態會話 cookie 中的密鑰可能被攻擊者獲取，authenticator 為什么不能被攻擊者獲取？獲取這兩個東西的難度有區別么？
---
TODO
| hash salt
| 彩虹表