Twitter 發了公告請大家改密碼：「Keeping your account secure」。不只是 Twitter 自家的密碼，如果你有重複使用同一組密碼，也建議一起修改：
Out of an abundance of caution, we ask that you consider changing your password on all services where you’ve used this password.
雖然使用 bcrypt，但因為透過 log 記錄下了未加密的密碼，所以就中槍了：
We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter’s system. This allows our systems to validate your account credentials without revealing your password. This is an industry standard.
Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.
這時候就要再推 Password manager 這種東西了，在每個站台都使用完全不同的密碼，可以降低這類問題帶來的衝擊...
Amazon 之前放 s2n 出來當作 TLS protocol 的方案，於是就有人摸出東西來：「Lucky Microseconds: A Timing Attack on Amazon's s2n Implementation of TLS」。
即使是經過外部資安檢證，仍然還是有找到問題。這次找到的問題是 timing attack 類在 CBC-mode 下的 plaintext recovery：
At the time of its release, Amazon announced that s2n had undergone three external security evaluations and penetration tests. We show that, despite this, s2n - as initially released - was vulnerable to a timing attack in the case of CBC-mode ciphersuites, which could be extended to complete plaintext recovery in some settings.
Our attack has two components. The first part is a novel variant of the Lucky 13 attack that works even though protections against Lucky 13 were implemented in s2n. The second part deals with the randomised delays that were put in place in s2n as an additional countermeasure to Lucky 13. Our work highlights the challenges of protecting implementations against sophisticated timing attacks.
It also illustrates that standard code audits are insufficient to uncover all cryptographic attack vectors.
Amazon 的官方說明則在「s2n and Lucky 13」這邊可以看到。
主要是參考「Cryptographic Right Answers」這篇給的建議：
Password handling: As soon as you receive a password, hash it using scrypt or PBKDF2 and erase the plaintext password from memory.
Do NOT store users' passwords. Do NOT hash them with MD5. Use a real key derivation algorithm. PBKDF2 is the most official standard; but scrypt is stronger.
Please keep in mind that even if YOUR application isn't particularly sensitive, your users are probably re-using passwords which they have used on other, more sensitive, websites -- so if you screw up how you store your users' passwords, you might end up doing them a lot of harm.
其中 scrypt 是作者自己發展的演算法，這邊看看就好。
你可以用 PBKDF2 (RFC 2898)。這邊假設的前提是，你不需要常常重複計算使用者的密碼是否正確。在這個前提下，我們可以把演算法弄得很複雜，而且很耗時，要複雜到用硬體加速也無法產生實質上有效的攻擊。
如果你對密碼學這個領域並不熟，Colin Percival 這篇文章可以拿來當做起點，文章裡面告訴你，某些類型的問題會用某些工具解決。