Ok, I want to be as constructive as I can here: 13:20 perhaps suggest a simple countermeasure like exponential back-off on those notifications, or since we know that the user pressed "no" the first time, immediate lock-out or freeze logins from that IP or to the account altogether? (Or explain why those types of measures were not helpful, if Uber already had them) 18:30 TOTP is an open standard, as you mentioned, which means the user could use any app either from a trusted 3rd party, or from an open source implementation, or one they built themselves, or one that you as an engineer provide for them, making it less worrysome that one company knows a lot about you. Additional benefit over U2F is that it relies on a device that everyone already has with them at all times, so there is nothing new to buy, and no additional item to bring with you. I would also argue that "setup and provisioning" applies to U2F. 24:34 you could reference NIST here too, the very same update from 2016 that you reference earlier says to have no rotation without reason. 29:00 very important point here that seems to go unmentioned: the xkcd password ignores half of the "rules" that most websites check for, but is still high entropy because of its length. Length is more important than uppercase letters and numbers. This is also mentioned in the NIST update from 2016. 30:00 another input from the 2016 update from NIST: stop doing composition rules, stop forcing people to put a number or a symbol in their password. What to do instead? Increase the minimum length, at least to 8 or 10, and check each password against a list of known bad passwords, like the top 10000 most used passwords from leaks. 33:00 don't recommend sha2 on its own for password hashing, it is not good enough. The only good alternatives are on the next slide. 33:50 the work factor crucially allows you to tune the slowness of the hashing to be as slow as your servers can handle, allowing you to aim for "1 second processing time" for example. And also allows you to update this work factor later, when your servers have become faster. 34:00 PBKDF2 - Password Based Key Derivation Function 2, should not be dismissed so easily, it can be important especially for enterprise applications that have to conform to certain regulations about what cryptographic functions can be used, as one of very few government standardized algorithms. 34:05 there is no password hashing algorithm named Scrypta, it's scrypt, especially manufactured to be resistant to GPU based brute force attacks. 40:00 this is maybe just me, but I'd argue the randomness shouldn't matter, if the increased delay is exponential, and grows quickly enough, the attacker should be limited to only a few attempts before they have to wait hours or days between each attempt. 43:15 big tech companies go against some of these, both Google and Microsoft will tell you if your account exists or not before allowing you to enter your password. I'm not saying everyone else should do the same, but I would have liked to see some good arguments of 'why can't I do like Google?'. 45:30 excellent question, but to counter it: if you store all passwords in a manager, you have a single point of failure, but you can invest a lot of effort in making that single point *very* secure, and rest easy in the knowledge that every password you use is 20-30 characters randomly generated and easily changed. Compared to using the same password for multiple accounts, where you have no control over the security that is implemented in each of them, and a hack on any one of them could break multiple of your accounts, and the attacker didn't even have to target you personally. For almost all users, it is more secure to use a password manager, because it allows them to have unique and strong passwords for everything while still being lazy.
And yet some popular sites and apps (yes, even those from banks) STILL refuse to add MFA despite users spending money on their accounts or having highly sensitive information.
you know you're in the future when the speaker adds their Mastodon username to the slides instead of Twitter
Ok, I want to be as constructive as I can here:
13:20 perhaps suggest a simple countermeasure like exponential back-off on those notifications, or since we know that the user pressed "no" the first time, immediate lock-out or freeze logins from that IP or to the account altogether? (Or explain why those types of measures were not helpful, if Uber already had them)
18:30 TOTP is an open standard, as you mentioned, which means the user could use any app either from a trusted 3rd party, or from an open source implementation, or one they built themselves, or one that you as an engineer provide for them, making it less worrysome that one company knows a lot about you. Additional benefit over U2F is that it relies on a device that everyone already has with them at all times, so there is nothing new to buy, and no additional item to bring with you. I would also argue that "setup and provisioning" applies to U2F.
24:34 you could reference NIST here too, the very same update from 2016 that you reference earlier says to have no rotation without reason.
29:00 very important point here that seems to go unmentioned: the xkcd password ignores half of the "rules" that most websites check for, but is still high entropy because of its length. Length is more important than uppercase letters and numbers. This is also mentioned in the NIST update from 2016.
30:00 another input from the 2016 update from NIST: stop doing composition rules, stop forcing people to put a number or a symbol in their password. What to do instead? Increase the minimum length, at least to 8 or 10, and check each password against a list of known bad passwords, like the top 10000 most used passwords from leaks.
33:00 don't recommend sha2 on its own for password hashing, it is not good enough. The only good alternatives are on the next slide.
33:50 the work factor crucially allows you to tune the slowness of the hashing to be as slow as your servers can handle, allowing you to aim for "1 second processing time" for example. And also allows you to update this work factor later, when your servers have become faster.
34:00 PBKDF2 - Password Based Key Derivation Function 2, should not be dismissed so easily, it can be important especially for enterprise applications that have to conform to certain regulations about what cryptographic functions can be used, as one of very few government standardized algorithms.
34:05 there is no password hashing algorithm named Scrypta, it's scrypt, especially manufactured to be resistant to GPU based brute force attacks.
40:00 this is maybe just me, but I'd argue the randomness shouldn't matter, if the increased delay is exponential, and grows quickly enough, the attacker should be limited to only a few attempts before they have to wait hours or days between each attempt.
43:15 big tech companies go against some of these, both Google and Microsoft will tell you if your account exists or not before allowing you to enter your password. I'm not saying everyone else should do the same, but I would have liked to see some good arguments of 'why can't I do like Google?'.
45:30 excellent question, but to counter it: if you store all passwords in a manager, you have a single point of failure, but you can invest a lot of effort in making that single point *very* secure, and rest easy in the knowledge that every password you use is 20-30 characters randomly generated and easily changed. Compared to using the same password for multiple accounts, where you have no control over the security that is implemented in each of them, and a hack on any one of them could break multiple of your accounts, and the attacker didn't even have to target you personally. For almost all users, it is more secure to use a password manager, because it allows them to have unique and strong passwords for everything while still being lazy.
And yet some popular sites and apps (yes, even those from banks) STILL refuse to add MFA despite users spending money on their accounts or having highly sensitive information.