Toward Better Password Requirements - Jim Fenton

lots of different and really good talks in the passage track I have to say that this is the tenth time I do the passwords track or passwords come this is my fourth year doing at the Las Vegas it's the third year I do it in cooperation with b-sides and the next passwords con is going to be at the university of bucum and germany in december for two and a half days and then it's a complete conference so there's absolutely nothing else but password related talks for two and a half days and there's a really good brewery just next to the University as well where we are going for an engineering excursion in the evening as

we say so I'm a good you know I used too much time up here our first speaker is Jim Fenton for those of you who have heard him before he's a really good speaker I really like the stuff he's bringing through us and today a very interesting talk toward better password requirements so Jim I will just hand it over to you and we get started thank you I think we're a couple minutes early but that's all right oh oh although we do as well I'll start a little bit slowly I'm Jim Fenton good morning everybody thank you for coming we've talked in in in passwords con and a lot of other venues about a lot of the

ridiculous things that we're putting people through in creating passwords you know composition rules expiration as as Laurie Craner just spoke for those of you that were in the keynotes and it isn't very often that we have an opportunity to create a set of password requirements or to kind of go through and rethink based on the research that's that's happened and so forth about what password requirements really should be and so this talk is an attempt to describe an F that's going on to do that that going on at the National Institute of Standards and Technology NIST but let me start with a with a little bit of a disclaimer we always have to start with a little

bit of legalese or something like that I'm a consultant for NIST working on the revision of SP special publication 800-53 I I don't speak for NIST I'm not Anniston ploy II so please bear that in mind even when I used the the pronoun we I you know really really kind of feel like a member of the team and and I haven't have a tendency to to refer to NIST as a we even though I'm not really in this person but bear that in mind and and then the other thing is that what I'm discussing is a what we call a preview draft and I'll get into what that means some more everything is very fluid at this point there are some

obviously there's there's been a starting point there's been a lot of internal thought and discussion about what that starting point should be that's reflected in the in the preview draft that's that's up and posted right now but these things can and will change and sometimes they can and will change on a daily basis so let me give you a little bit of context about where it is that we're talking about creating a new set of requirements special publication 800-53 which in the past has been called electronic identification guideline for for various reasons we're calling it digital with an occasion guideline now is a response to another document that was created in 2004 by the Office of

Management and Budget in the White House and that document which is called mo 404 is a it defines a set of four levels of assurance that and in how to decide what level of assurance a particular government application is based done you know what the what the risks are and you know whether you know maybe there's a threat of of life or whether somebody's privacy might be breached or any number of other things and so it provides a basis for for categorizing federal applications into these four different levels of assurance and then 800 s63 was created in order to respond to that and say okay here are the things that you need to do with identity

proofing with authentication and with assertions in order to respond to each of those four categories of applications the the the publication as I have been saying is primarily oriented at federal government agencies although a lot of other people have adopted it for other applications as well there's a major rethinking and rewrite of 800 - 63 that's going on and a lot of that has to do with an executive order that came out about a year and a half ago which mandates the use of what they call an effective identity proofing process and multiple factors about authentication for a lot more applications in particular anything that citizens consumers might log into and obtain personal information so thinking of

Social Security IRS Veterans Administration those sorts of things that people log into that they might obtain personal information about themselves from are going to require two-factor authentication we've here's here's the first use of we missed has broken this into four documents there's a sort of a top-level document which is 800 - 63 - 3 3 being the revision number and then there earth now three sub documents that are new 63 a which deals with identity proofing which is the the process of associating a particular real-world person with an online account how do you make sure that this person corresponds with that account 63 B which deals with the authentication process itself and that's where I'm going to be focusing

most of this talk and then 63 C that deals with assertions that would be used in a federated identity system where the verifier of the identity is not the same as the party that you're actually logging into now one of the things that this update has is a few guiding principles and and these aren't written in stone anywhere these are just some that I jotted down but these are characteristics that I think have been informing the the process of this revision we really want to do something better in terms of user experience we've you know talked in the past at passwords con about all of the things that users might be required to do and they always

find a way to cheat and so if you make it too difficult for users they're going to find a way around it and and not not achieve the level of security that you want anyway we want to have realistic security expectations as I mentioned earlier two-factor authentication is going to be required for more things so a password as a single factor we were recognizing has a useful but not a an ultimate level of security we're not trying to lean on the password too hard so we therefore don't want to put users through a difficult process in order to try and achieve something that we're not achieving anyway we want to try and put more burden on on relying parties

websites verifiers as they're referred to to do the right thing in terms of the way they store credentials the way you know the kinds of credentials that they accept rather than to put more burden on the user and we also don't want to ask in this kind of repeats with what it said earlier we don't want to ask users to do things that are really just not helping so some of you may not have worked in the standards world before but we have different levels different terms that we use that are levels of requirement so the highest level in and I'm referring to now the the NIST usage of these terms and I'll kind of compare them with with

IETF that I'm also familiar with the highest level is shall which means that it's an absolute requirement IETF you tends to use the term must instead they're more or less equivalent theirs should which in the NIST formulation is is as it describes their IETF is maybe a little bit stronger it's that there may be good reasons to ignore this but you should really understand the implications and in other words have a good reason if you're not doing it should this is maybe a little bit not not quite that strong of a statement may of course just means it's something that's permissible and although IETF actually puts in some being concerned with interoperability a lot ITF also puts something in there

that if something is a May that you also have to consider the interoperability consequences of that so this being passwords con I'm going to focus on what the document calls memorized secrets which we commonly call passwords but also passed phrases and pins I tend to use memorized secrets in order to be inclusive of all of those things unless I mean a particular one of them like particularly we we distinguish pins in some cases from from others so here's a quick summary of some of the things that are that are changed different in the in the new draft as it stands right now of course memorize secrets need to be at least eight characters in length and that the

relying party should accept long memorized secrets of up to just 64 characters and I'll talk about the rationale for that a minute we're using a dictionary in order to disallow common passwords and and we want to be very liberal with the character set and what people are allowed to create their passwords from we don't want to impose a lot of mental burden on try and say well gee no that that particular character I'm not allowed to use here we're getting we're discouraging the use of composition rules hints for passwords knowledge based authentication is gone and routine password expiration is also discouraged so let me go into a little bit more detail about those so in terms

of the minimum length we've there are really two different requirements that you could try to meet for minimum length one is to defend against online attacks and the second is to defend against offline attacks as well online attacks you have the advantage that you can throttle limit the number of guesses or limit the rate at which guesses of the password come in so it's a it's an easier requirement to meet offline attacks of course you're dealing with potentially the the compromise of the of the credentials and you're expecting that people are going to create something that's that's really very difficult to to brute-force it's extremely hard to do that though the and we've talked about this all

in past password passwords cons and so we're really focusing on defending on against the online attacks here we've had a few comments saying gosh that's an awfully weak requirement only eight characters shouldn't it be more than that and you know there's maybe some discussion about whether it should be ten instead of eight or something like that it making it dramatically more simply drives up the drives up the the the mental burden for people who are trying to use these systems and we don't think that we're going to get to the point of being able to adequately defend using length against offline attacks in any case the other thing that we're doing here and and this is kind of a general

comment about the about the specification is to be trying consider trying to be consistent about the requirements at different security levels so at different security levels what we call Authenticator assurance levels ALS the requirements for a memorized secret are all the same as you go to a higher level of security though if you go from a l1 to l2 it becomes a two-factor authentication and in a l2 to a l3 requires a hardware factor as well requires that one of the factors be Hardware so we're trying to be consistent about that and the the the old limitation of six characters at LOA one was thought to be a little bit too weak so maximum length the specification

didn't talk about maximums at all before and we've seen all sorts of situations where you know you're required to have at least eight characters and at least six characters and fairly near a range of lengths there isn't any reason in terms of storage or anything else why the length can't be fairly liberal we want people to generate something that is memorable to them and we want to constrain that as little as possible so the the specification says that the the verifiers shall accept memorize secrets up to 64 characters in length they can do longer than that if they want and 64 characters is a you know kind of fit sauna that's have a lot of screens it's not an overly overly

long thing para was asking if we have any research that it fits on many screens no we haven't the the there there hasn't been any any particular investigation that was you know a little bit of a kind of let's let's let's put in a number and and and see what people say about it so that's if if people feel that that's inappropriately large I I wanted pointed out that a standard terminal is 80 characters wide and and and I think you know that's somewhat somewhat the rationale although it's a kind of an old-fashioned rationale mentioned that we're not displaying passwords anyway but stand by I'm sorry porta it's true portable devices are not 80 are not 80 characters so you know

they're there there may be some question some question about about this on mobile devices but the point is let's not make it an eight character minimum and a 10 character maximum or something silly like that fifteen i I won't comment on Microsoft being 15 but but the point is when you're storing the password you're going to store the hashed value anyway it's a constant length so it is really not a burden to try and accept a somewhat longer password then it is to just accept a 10 or 15 character password now their head somebody has pointed out that if we were to allow like multi thousand character memorized secrets here there might be some potential of a DDoS attack

against the verifier through the multiple rounds of hashing that you're doing and and you know so fair enough on that maybe you don't want to go too crazy and allow people to use warren piece's their memorized secret but you know a length of you know on on this order is not should not be burdensome for the verifier now we're talking about usability I think Peres was asking if if there were usability people in the audience here we have some some really good usability people there's that we again NIST has some has some really good usability people they have assigned to to this project and one of the things that was kind of surprising to me was

the the comment that they made about space characters they were concerned that you know people would either forget to put in spaces when they're typing their password not remember whether or not they'd put spaces in when they when they created it or maybe there would be things like they type two spaces and it would be kind of an invisible failure so the thought here is that we definitely want users to be able to type spaces in their memorized secrets it's a natural thing to do but they don't really add that much extra entropy or randomness whether they're there or not so we allow for the possibility of canonicalizing the mouse essentially stripping the space characters and then

hash and store that value and you know it provides yes it provides a little bit of a wiggle room when when if an attacker were to get a hold of the password and all of that but really if they if they had enough information to get the memorized secret anyway it really wouldn't add that much extra difficulty for an attacker to figure out where the spaces ought to be okay character set the the previous version of the specification said that the alphabet had to be of 90 or more characters and this was largely from the standpoint of trying to estimate the possible entropy and and that was a that whole process was a little bit fraught

the the new specification is saying that the verifier shall accept all printable ASCII characters now we see all sorts of exceptions to that now where they're you know we won't accept double quotes or only accept you know certain other characters and you look at some of these requirements you say oh gosh it looks like they're trying to predict against SQL injection attacks or or something of that sort that shouldn't be a problem before it goes anywhere near a database the memorized secret needs to be hashed and so the hash isn't going to contain those values so why do we need to constrain people from using all of these things we want to make it as easy for the user as

possible we're not we're not trying to to turn this into a contest here we're also saying that they should accept Unicode characters and yeah some people like to put emoji characters in their password that's that's fine I guess but I think it's also very important from the standpoint of international users users you know even for the for the federal government there's an awful lot of consumers that English is not their first language and something memorable might not be expressed in the English character set so we're trying to get away from all these usability problems and hopefully this will this will help hints and prompts we see sites that in fact I just ran into this when I was

setting up Windows 10 the other day where it says you know you need to provide a password hint and it's we really think that it's training people not to treat this seriously you get password hints that are of the form my password is blah and you know obviously that's that's not that's not helpful so in and I've even seen attempts to try and make sure that the password hint doesn't contain the password and you know it gets to be kind of a kind of a point-counterpoint sort of thing so we're just saying shall not permit the provide permit the user to store a hint and shall not prompt the user with particular types of information that should be used as their

password and we'll get to knowledge-based authentication in a minute just just because that weakens everything throttling is a tricky business we want to throttle in order to protect against online attacks but if you throttle too much you're going to essentially either make it hard for the user or create the possibility of a denial of service attack against a particular user if somebody wants to you know harass somebody they could potentially make it so that they can't log into their account somewhere so we've not the the previous revision of of 863 had some guidance in there about things that could be done in terms of using CAPTCHAs white lists and various things that could be used to try

and mitigate the possibility of an attacker coming along and trying to lock somebody out of their account those are largely unchanged and but we've we've still gotten some comments about things like well gee you should you should make the failure count based on IP address or something like that well the problem here is that if you do if you do some of those things you got to remember what what the capabilities are that the attackers have attackers typically or quite a few of them have access to lots of IP addresses maybe they have a botnet at their disposal that they can use for proxying and so forth so we don't want to weaken the whole throttling business

by making it possible for an attacker to game the system as it were especially when use it using the using the IP address is probably still going to have the same impact on a user that doesn't legitimately remember their memorized secret and by the way we're using this throttling in and some other places in the in this specification as well the some places like when you have a one-time password you know from a key fob or something like that and it might have a six digit number that's roughly 20 bits of entropy I guess and in in cases like that where the entropy of the of the verifier I'm sorry of the authenticator output as

it's called is relatively small throttling is also required there

we've all run into composition rules and we've talked about them a lot at passwords Khan in the past of course these are the rules that say you need to have different classes of character uppercase lowercase digits but there are a lot of other more complicated things that that people are asked to do you know don't have consecutive more than three consecutive characters that are the same or it gets to be a real mental exercise to try and come up with a password or a memorized secret that satisfies all of these rules and they're different in different situations you have to sit there and study them for a while sometimes and they don't do that much good research is found so the new

the the draft now says that the verifiers should not impose compositional rules and but should instead use a dictionary a blacklist if you will of disallowed memorized secrets it doesn't say a whole lot about how to create that dictionary I think that's that's something that might be a little bit too I'm not sure that we have that that we have enough information about exactly how that ought to be done and that might be done in different ways in different situations well we'll talk a lot more about dictionaries here but I mean the rationale of course is that that composition rules are just really hard on users because they actually allow you to use the the opposite case

version of your password to log in so if your password is capital P and lowercase password you are actually also allowed to log in with lowercase P and uppercase password they do that okay that's that's simply because when you have one point four billion user quite a few people actually have caps off turned on and that we're not supposed to it's not something that Facebook I think they came with that like maybe two years ago okay para notes that Facebook has some ability for users to enter passwords in the opposite capitalization I guess that's a that would come less as a as a composition rule but maybe is another form of canonicalization yeah right right so if

it fails it just it just tries again the question is what won't we have a situation where there are too many known secrets and you have problems with that stay tuned that's the next couple of slides up and back some I see a hand

a question is if I want to deliberately use an insecure password why can't I part of part of the issue here is that the user in in many of these cases the user is not the only one that has a stake in the in the privacy in in the the security of the account in a healthcare situation or something a lot of a lot of other sensitive situations if there's if there's a breach it's a significant burden on the party that you're logging into as well in order to disclose and mitigate that breach so there are

never it that it companies it's it's never explained to users the the why they have this burden I agree there there needs to be some better training there we're doing our best to you know make the make the burden on users to mitigate the burden on users but we can't make it go away entirely alright so let's talk a little bit more about dictionaries I mean one of the questions that we that you might ask about dictionaries is sort of how big should it be if it's too small if the dictionary has ten entries in it then there are an awful lot of frequently guest passwords that are still allowed if the password is enormous then you're basically making it

very hard for people to come up with something that isn't on the list so that that's one question a second question and I was talking with with Lorri Craner about this a little bit earlier what happens when we when we when we use just a dictionary like this well users do something predictable when they're told that I'm sorry that's not an acceptable password so will they do something like put a one on the end put an exclamation point on the end just something very minimal in order to try and get around the the dictionary that's a subjective or a little bit of research and I and I understand that's that's going on and if we do have that possibility of course a

dictionary becomes a great resource for somebody that wants to do some offline cracking is like here's the starting point now just apply the following however many transformations to the entries in this dictionary you know maybe change all of the two ones or or whatever you could do the leet-speak sort of transformations you know you you know you guys have all thought about a lot more of these than I have but you don't want the dictionary to be necessarily something that is going to help the attacker attack memorize secrets and that's it that's a concern so I decided to play around with dictionaries a little bit how you know how big of a dictionary is effective and

and and what's in it so I started Mark Burnett has curated a list of 10 million compromised passwords and that I thought that was a good you know kind of publicly available starting point so I took that list limited it to the entries that are 8 characters or more and got about half a million entries and about 3.2 million distinct passwords and here's kind of what they look like and you know this is a distribution that you that you kind of expect this is of course log distribution vertically but you can kind of see down the just kind of a sampling of the things of course password is the number one password but we've got some

some interesting good Moda pass which is the French one and this you know the Welcome one two three and then you get down here and they get you know a little bit pc-7 FDD mhm that's a little bit more obscure so it kind of has the right form this was a pretty useful list there are an awful lot of passwords that are of the form of a date which is maybe more than we expected there but you know you're probably not going to get any sort of a any sort of a list that's absolutely pristine one other thing you can do is you can do the the log log graph which ideally for a Pareto distribution like

this should be a straight line it's got a few bumps but it's got about the right kind of distribution so kind of think that we're doing roughly the right thing and so on this graph if this is if you've four example more than three occurrences of a particular password in the list there are about a hundred thousand entries so you probably don't want to disallow every password that has ever been used in your corpus you just want to disallow the ones that are that are commonly used so the point here is that we we start with a corpus of several million and we get down to a fairly manageable number fairly quickly just by disallowing the

the the passwords that are there are one two or three times and that doesn't necessarily need to be the way that it's created but it's just kind of an existence proof I think really so it was pretty simple for me to build or what seems like a reasonable dictionary of course I don't have any real testing to indicate its effectiveness but we still have this problem our if bad password is on the list we'll users try and change their password try and use bad password one instead and you know that would be a there would be a serious shortcoming of this of this whole thing and hopefully we'll find out from from some research about that fairly soon now I talked

earlier about trying to put a little bit more of the burden on the verifiers on the nonhuman side of this and the the previous versions of SP 800 - 63 you know had some had some guidance there it said fortunately said shall not store plaintext but of course that's not very much of a requirement it could be just hashed once or not even salted anything like that and of course that was a tell away one which we discussed earlier was a little bit a little bit weak at Loa two and higher it says that it may you may salt and derive the key or or encrypt which again it's a May it's not a very

strong requirement of the of the specification so this was something that needed to be that needed to be strengthened and so the draft now says that the memorize secrets shall be hashed with a 32 bit random salt using an approved key derivation function of course the the requirement for using approved functions is kind of throughout the specification it you know there are some popular things like bcrypt that are not currently approved functions but if you're not a federal agency you can perhaps don't need to to deal with the approved aspect of it as much we say that it should should be done 10,000 iteration rounds this is of course to drive up the the work function

for attackers and we also say that it should use a keyed hash like H Mac with a key stored separately because and this is really important if you if you use a keyed hash and the key is not breached then there is really no offline attack possible and that's the best of all worlds now you don't want to put all of your eggs in one basket or all of your eggs in one key not being breached so actually it might be a good idea to do both of those things but we really want to encourage or require verifiers to do a better job of storing the values that they used to verify memory secrets and now we get to the point of talking

about displaying secrets and and this this came up earlier this was some more input from the from the user experience team at NIST which basically said that you know in an awful lot of situations people are trying to type and we're trying to encourage people to use longer memorize secrets and they're trying to type memorize secrets in a situation that there isn't anybody else around they're sitting in their office at home or something like that why not give them the option why you know there are sites that do this now why not give users the option of checking a box and making the making the what they're entering visible and you know of course you don't want to

do that in all situations you you really do want to obscure it in situations when when people are likely to be shoulder served but this this is something that I think will encourage people or make make people more confident in creating longer and therefore more secure memory secrets and it just kind of takes takes takes the burden off expiration Laurie Craner in her inner keynote talked a lot about the expiration of of passwords there was the the specification before was silent about this it's now saying that verifiers should not it's not an absolute requirement but it's a should not require memorize secrets to be changed periodically or otherwise arbitrarily of course if there's a breach or something

like that you should absolutely require users to change the passwords but just doing it for the sake of doing it is thought to cause if not negligible benefit it perhaps even more harm than good now I'm going to broaden out a little bit and talk about a few other types of authenticators besides passwords because there's a lot more to the specification and I've been talking about a very narrow piece of it previous versions of the specification had a thing called pre-registered knowledge tokens token and Authenticator are synonymous we're using Authenticator now in order to avoid other conflicting uses of the word token like in oo auth tokens and things like that that has been eliminated in in the new in the new

specification there is no longer a pre registered knowledge token and I think we all know why it's because the there they're much they're they're subject to reuse and they're not very strong in the first place so questions like your your first pet are no longer allowed it's been a lot of talk in the last week or two about out-of-band authenticators and I'll get to the to the question of SMS in in a minute here but the the the point of a of an outer band Authenticator is it should be uniquely addressable and separate in some way of course virtualization makes the question of separate a little bit vague er but the communication channel that it

communicates over should be separate from what you're authenticated on there are some new some new possibilities here to where the response can actually pass over a protected Channel it can be kind of more of a more of a one-way in the in the opposite direction from you know what what you might think I've stayed with SMS and the part of the idea here is since we're requiring that it be a uniquely addressable device there's a requirement now that the device authenticate itself using approved cryptography in order to establish that it's that it's a unique device and a particular device because this is out-of-band authentication on something like a password so we're trying to prove the possession of a

particular thing SMS there have been some pretty high-profile breaches I believe Laurie Craner actually had one as well and litera Levison who's known for the lavabit email service and DeRay McKesson of black lives matter all suffered breaches that were contributed to by compromises in SMS based two-factor authentication and who knows how many more there are that we that we don't hear about but the point here is that there's both kind of the the physical security byte of the device and the you know whether or not they you know ss7 network could be compromised I I don't actually know of any of any ss7 based attacks on on the SMS to factor but there are there's also a very

substantial ecosystem around mobile phones where you know every outlet that can sell you a phone and basically is empowered to you know help get your current phone number assigned to that phone and we're depending on the reliability of thousands and thousands of retail clerks in random stores all over the place in order to make sure that someone's telephone number isn't assigned to an attackers telephone that I think is the biggest weakness in this whole system it isn't it isn't so much of a technical weakness as a social engineering weakness and I think that's what's happened with a lot of the sms attacks that we've heard about there are also there's also the possibility that a that a voice over IP

phone number can be used and of course if if you're using a VoIP phone number it is improving the possession of a device at all and that's why it's says shall not be a VoIP number that's that's just not just not proving possession there are a number of changes I could probably give a whole hour-long talk about biometrics so I'll just kind of touch on briefly the the requirements actually haven't changed that substantially in terms of how they can be used a lot of people were concerned about the fact that there were fairly limited uses for for acceptable use of for biometrics in the in the previous versions of the specification but they they still need to be bound tightly to a

specific device that's doing the authentication you can't have the situation of where you have you know maybe a retail store that you use your thumb print it at any cash register or something like that you need to really enroll the the biometric with a with a particular verifier and therefore every time you using a biometric it sort of becomes a multi-factor authentication not only the biometric but you're also proving the position of the device so that's kind of where biometrics are special they're always multi-factor in the in the accepted uses here there are now performance metrics that are required for for biometrics in terms of the false match rate the false non match rate I won't go into the specifics but

they actually aren't as strong as as I expected that they would be based on apparently what's being achieved and there's a hard limit now on consecutive field attempts very much like if you're using biometrics if you're using fingerprint on your iPhone after a certain number tries they'll say now enter your PIN that's kind of kind of what's required here and it has to do with what those performance metrics actually are that can be achieved so you still need to have some sort of a backup for maybe a memorized secret to use if you if you hit that hard limit of of ten failures one thing that has been liberalized is that verification can be performed

centrally providing you're still binding it to a particular device and meeting all of the other requirements so I'm going to talk briefly about how everybody can participate in this in this process we've we're doing something very different this time from the from the normal special publication update process the the there's a preview draft that's available right now you can look at this URL and if you can't remember it all just remember pages miss gov and then gives you a directory and you'll see 800 s 60 3-3 at the top but it's it's a it's it's live off of github so as changes get get cranked in and so forth this this document changes sometimes several times

a day so you know have a look at it please do submit comments there's some some guidelines on how to on how to do that you submit the comments right now by issues on github some people have actually submitted pull requests and you know you can do that if you want but issues issues are fine and the idea is that we're doing a very open and a very continuous integration sort of revision of this document and thus far it's been working out very very well the public preview period runs until the middle of September or so and then after that there will be the standard formal comment period because not everybody's comfortable with with this this model

with with github and all of that but we're really hoping to get as many comments as early as possible and have had that formal comment period perhaps be a little bit shorter than it might otherwise be so that's about it if there are any other questions I'll try and handle those in the time remaining yes sir this is just for federal agencies and then that's not true anymore because SP 800 170 one's already hit us or is about to hit many of us and so we're already now being told fibs validated cryptography for confidentiality this could be the next thing that becomes mandated upon the general industry so it's not just for federal agencies and

that's that's fearful if the bar is raised too high we're mindful of the fact that SB 863 is is used quite a bit outside of the outside of the federal government at the same time the there are some you know significant concerns with things like storage of credentials and the places where two-factor authentication is required where things either just really do need to be improved or they're actually mandates like in the executive order that came out the saying that you know we need to do two-factor authentication in a lot more cases and so we really need to figure out how to do that more at scale and but thank you yes one simple question so it seems

the majority of the spec is being guided from the perspective of the user and user experience we'll there are there guidelines on foiling common malware strategies like key loggers and other attempts to circumvent or capture that user data such as if you're displaying the password and there is a screen capture tool on that device what would you do so that that's a good question about a screen capture I'm I'm personally been thinking about the question of malware or mana the browser man-in-the-middle attacks quite a bit of course yeah there is I guess there is a new there is a new risk of you know displaying the password if if a screen logger is there but I don't see that as

being any more likely or likely to be there at times when there isn't also a key logger so I don't see that as being a significant new and additional weakness that that's introducing okay last one before we do our short break so that a couple quick questions so when you mentioned the ativan process with SMS I think what I heard from you is the basic reason that that is being cut off is because it cannot authenticate the device is that correct that that's right because the the what outer band is trying to do is trying to establish possession of a particular thing okay and then real quick the requirements for authenticating the outer band provider

or even other non-human base devices or the other is there any call out in this section or in the specification about are the standard about that so I'm thinking like app passwords and even you mentioned that the outer band provider has to authenticate is are there special requirements for the Authenticator I think like right now we commonly see some sort of like 64-bit random keys that are generated for some of these tentacles or passwords than to then left forever as far as you know like API keys etc similar right um they're really the requirement for out-of-band is that that the device not not so much the provider but the the physical device be authenticated and and it needs to pass

through a secure channel so hopefully the provider is kind of irrelevant there I mean there are other tort other sorts or lookup secret authenticators that it didn't really talk about but you know you'll see them there in the in the specification that probably correspond better to your example of you know like a 64-bit thing that might be you know printed and you store in your strongbox or something like that okay that was the last one so thank you Jim