There is a nice article about improvements to Twitter logins: https://blog.twitter.com/2013/login-verification-on-twitter-for-iphone-and-android
The general idea to "bless" new login attempts using one of your devices that you carry with you seems like a cost-effective idea to improve security for large sites. I'm only surprised it took us this long to see it happen... But what caught my eye was the following paragraph about backup codes (used when you forget your device, or more interestingly, when your device doesn't have network connectivity, which could suggest it will end up being used more often than for device recovery): To make the backup code work without sharing secrets, we use an algorithm inspired by S/KEY. During enrollment, your phone generates a 64-bit random seed, SHA256 hashes it 10,000 times, and turns it into a 60-bit (12 characters of readable base32) string. It sends this string to our servers. The phone then asks you to write down the next backup code, which is the same seed hashed 9,999 times. Later, when you send us the backup code to sign in, we hash it one time, and then verify that the resulting value matches the value we initially stored. Then, we store the value you sent us, and the next time you generate a backup code it will hash the seed 9,998 times. The S/KEY system security was O(2^64) because hash truncation was to 64 bits, and to mount an attack you can pre-compute a table and there is a space/time-tradeoff if you want to reduce O(2^64) storage. (See for example https://www.miknet.net/security/otp-weakness for details, you could have O(2^42) storage and O(2^22) work.) Twitter appear to truncate to 60 bits. Does this lead to precomputable/compressable O(2^60) security of their system, or am I missing something in the still too-warm-to-think summer wheater...? /Simon _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography