PG - Two-Factor Auth - Demand Bidirectional - Joe Kirwin

everyone yeah I know of questions probably because it's been recorded maybe save them till the end normally I'd say just interrupt me so you don't lose your train of thought but if you save them to the end so the recording to go here I guess so yeah I'm Joe Cohen this is talk about some of the shortcomings that I've perceived from two-factor authentication both push and time-based one-time pad HMI based one-time pad and a proposal for some designs that I think could mitigate some of those issues feel like I know you ok so anyway if you don't take anything else away I guess the problem with 2fa that I've found is that it's got abused

from its original design so when the RFC was first buyout in 2005 for HMI trace one-time pad the design was supposed to be for mitigating you know consumption of breach data but since then it's being proposed to be something that will protect you from phishing and something that will protect you from confirming something out band so each of those the second one is in reference to push bass to FA the first one applies to push-based and also totp to fret to so just to bring everyone to the same level I know really most of you already know how the OTP scheme works most likely better than I do but if we go for the first one which both of these are

counter based one-time pads totp and hatred CP both use this H Mac design and the reason they use that one is for integrity of the code but also because H Mac is collision resistant under truncation they can truncate something very long so if six character to string and still have the integrity guarantees of the H map so most of them what they do is they change this hate map counter and here this is the thing that varies amongst all the different schemes but the majority of the schemes are just hecho TP or totp which is this other one and the way this one works it just takes the time from epoch and so now subtract that from when the token

was created divides up by a period which might be like 30 seconds minute whatever and then it just flaws that to give you an integer value and then essentially that just becomes same as the normal account base one time bad and that's that's all it's doing when it's sharing the QR code you know with you when you take the QR code and that goes into your Google Authenticator all that's doing is transferring the secret and the time seed so yeah what's the problem with this so if I was to talk through something Jamica with the type attack here we have live calm so this would be like the Microsoft domain and if we look at another domain that I

could purchase that would be AI ve calm and if I capitalize the high it looks indistinguishable from live calm I can also get a TLS certificate free from let's encrypt and then simply just forward across these details and I'll show a demo of how we could go about that in a second did we encounter this type of issue before and the answer is yes we did in around 2005 when they released H map based one-time pad there was also a scheme called cram md5 that some of you may be painfully like aware of that we don't use anymore right anyway so they found this to be an issue they cited it and they cited this attack at the same

time that the RFC came out for hm at base one-time pad but interestingly enough these two parties never discussed those things together so I'll just move to a demo and also check that this is all right for everyone everyone see that okay from the back and so so this what we've got here is is anyone familiar with Heroku anyone's used Heroku so I took a domain called Heroku comm just with spot with an eye instead of an e and essentially if I just drag the video back it's really easy to create these types of things like all you do is just save that page and then you just do a bit of like if you're cheap like me

or you use like Photoshop if you're like a rich man and then you just like change the characters to make it look indistinguishable from an actual Heroku thing I didn't actually purchase this domain because I thought that would be somewhat kind of criminal so I just instead just put an se hosts entry for this so excuse me if this is not a legit SSL certificate but this domain was available so I could have bought it I just didn't want to kind of blend blur the lines between white hat and black for this one and then the other thing we've got is just an Android emulator here which just comes with Android studio is just a qmu emulator and in the

top thing this thing you can see here this is essentially just watching the folder directory for the screen captures are about to get yeah so this site I'm just gonna put in my primary factor here you can email that domain if you on all that email it's not I don't really monitor it spam away so we've done the primary factor and then on the back end I've got phantom j/s running that's just running somewhat headless Chrome with some actual rendering features and it's just adding the first factor and then it's taking the output of that first page and then just waiting on that and then we put in the second factor here so I've go to my free OTP put in the second

code and what I did here is I put a really long time out to kind of emulate some sort of server-side error that might happen and then I redirected to the actual site here so this is the real Heroku now so what's mostly likely happening for the user now is they've had this fish email they went to log in to Heroku my fake one and then after that failed I just redirect sends the real Heroku then they'll probably complain to support that there was some sort of issue with the logins and as we can see now if we look at the filesystemwatcher dashboard should show up eventually once my thing finally screencaps it and I'd saved you an app

for all you guys called b-sides Las Vegas 2017 on my dashboard in Heroku just to show you like that we did get the real Heroku here obviously you could go to greater lengths with this you could for example do full video store you could actually get like session cookies and then just browse to that as an attacker but essentially you have that session once you've completed this and so that's one of the shortcomings of TOTP or HTTP doesn't defend us from attacks that target a specific platform it would defend against you know compromises of passwords but not from a targeted attack like this so when I was thinking of the issues here I thought of the desired features

of the solution that we'd want so firstly obviously we wanted to protect their to protect from an attacker stealing the users credentials so the primary factors and that would be vie dns hijacker tax so whether that's some sort of DNS change of malware some of the router hacks etc we'd also want a hammer glyph hostname protection which is not something contrary to popular belief that TLS would give us TLS you can have a secure channel to a bad place right it doesn't help with that and then we also want to protect static inputs with variable inputs and what I mean by that is if you think about the primary factor you don't frequently change your

password with totp that code is changing every 30 seconds so we'd rather put anything that's changing first because compromising that is not those Cass traffic is compromising the static factor and then also it'd be nice if it was technology agnostic so you know someone could write a design that maybe some UML some sort of like RFC and then it can be able mented any language you know your favorite language I'd rather it wasn't a proprietary piece of hardware and that was the comparison I'm making that the other thing is it may be in my perception if the people that I know it seems that we've reached a point where two-factor is just a thing that

people use and users have kind of said okay we're okay with this level of friction so I prefer not to add to that but if we could make it seem like it's just about the same level of friction base add in some more enhancements that would be ideal less friction would be desirable but if we can't do that the same level of friction could be okay so a proposed solution weirdly enough if we look at the original RFC from 2005 they even said interestingly enough you can actually use this in a bi-directional type way and I only found this after thinking of a design to protect it but essentially the way that this works is the user would enter their

token the server would send back is token and they both verify each other's page mac-based one-time pads and so there's there's two secrets in this exchange this wasn't widely implemented by vendors at least I haven't seen any vendors implement this I don't necessarily think it's much more friction than what we already have the only thing about Hecky OTP is it's not great for multiple clients sports because you have to keep counters in sync so imagine you have like a counter one that's incremented here and this other client doesn't know about it this one's going to be out of sync with this - it's hecho TP generation the good thing about time-based is that's a universal counter and providing there's

no attacks on network time protocol or something like that that keeps all the clients in sync and so the one that I chose to use was TOTP not hate your TP I'll get to that so what I'm proposing is say we take this this example of this live comm this Microsoft site and then I've got this spoofed I've calm so when they use the first visitors is that it sends a header and the reason it's sending the header is just so that the browser extension that I've created I can just listen for other headers that coming through ideally this would be baked to the browser but you can't do that until you've proved that it's

actually valuable so then they would submit they username I feel like giving away a piece of username is not a totally sensitive credential so it's okay to release that the server would then send back something called the next fearless response and the only variant that I've made here is I've concatenated to the flawed counter that we have this thing I've concatenated an IP block so this could be for example an IP range it could be a static IP that used for logging in it could be an ASN number just something that is harder to attack than DNS and so the the attacker now would have to go after the Box directly and compromise that box and in that

scenario you need different protections and so what this does it stops a site in the middle from then utilizing this totp code and passing it down the chain because the browser itself is going to do a dns resolution against I've calm so the browser itself will do a DNS resolution against I've calm it would calculate the expected OTP ker and that would be wrong because the actual code came from this one down here and here I've got a demo of that so what we have here is in the top window this is a cycle violence Pro these are real sites now I'm not like I was allowed to buy these because no one cares about these so this is

violas Pro this is a real site this is the one that we're gonna try and legitimately log into this is a Hamid glyph attack this is various Pro slash login and then up there we just got the browser extension that I created and that window the bottom is just a debug window for any extra information you might want so what we're gonna do here is we're going to log in with this user one password fubar so first of all we have to register with this site and what's interesting about all of these schemes as the registration is the most dangerous part of all of this process so it's the place where we need the most

hardening the most detection everything but that is indifferent across all these schemes so once we register it's going to give us a server secret and that the time were secret was created out and we can just populate that and the browser extension obviously if this was a production piece of code it'd be more slick than this it wouldn't just this is more to illustrate what is actually going on to you guys to kind of show as a proof of concept so now the extension is going to be listening for that particular type of OTP code to come across so if we go to login on the legitimate site what we're gonna see here is that I've put in user 1 I'm

gonna then receive a if you see in the top corner we've now got the the TOTP code that came up as a notification this is the client code so the extension itself has already verified the surfers the server's TOTP code and check that the dns resolution for that was legit so there's no site in the middle in this case and then if we was play if we continue I'll show you how we do that against the site here that's a Hama glyph attack against this and how it resists that in this case this is using a beta feature of Chrome called declarative web extensions which I'll talk about in a sec and we see here that

it was actually blocked we've got a notification say various top Pro is blocked this is not actually the legitimate site and that's what we prefer we prefer that there was some sort of smarts in our browser to protect us from losing our credentials in that way this extension just will not give up the client code unless the server code has been verified that's it for that demo so yeah what just happened here so it was a fan of UML I'm expecting no hands like I'm yes you guys are the best like I really like plant UML I think it's awesome and you can also generate in ASCII who doesn't love ascii diagrams of like networks like this amazing right so

anyway this is this is the flow of what happened so can you see my mouse pointer you can write so anyway the user requests the site then they get this x fields in it and what this does is it registers with these Google Chrome's declarative web extensions that it wants to listen for some sort of dynamic input from a header and this is great because your chrome extension could have like a secret cache and you can generate dynamic headers that it wants to listen for I don't know Firefox has this it might have this I just haven't tried it yet then you input your username now they need you a post request and it will

receive the TTP code from the server and what the extension then does is it uses the dns resolution api to say okay where did that server tcp come from and it came from this IP then what it does is it checks are these valid so it computes wherever it was great-great-great-great-great where is it it computes this thing so this is what the client is going to compute based on the dns resolution that I got and it's going to compare that to what I received from the server and then after that it's just a normal flow I mean this this kind of things arbitary after this you don't really need to use client TOTP don't use a password you can use

whatever you want you could use whatever scheme after that it's more this step that's the most important that the is is this valid comparison here and so the benefits of this scheme is credential phishing somewhat goes away because you're protecting the user from submitting this ephemeral code accidentally to a site that's using DNS hijacking so the the only way that the attacker could really go about attacking this one is attacking the client directly via malware breaking into the chrome sandbox or something like that or alternatively breaking into that actual legitimate server anything in the middle is somewhat protected by this scheme the other thing that I want to kind of labor about is the corrects the

user trust model I thought about drawing a graph for you guys but I think it would be too confusing because I did not find it helpful looking at the graph so essentially if you think about when you sign it for LinkedIn or whatever site you want when you first sign up that asset has no value there's no actual user details in there it's just an empty portfolio right so that things of low value but as it goes on over 10 years it increases in value so compromising a 10 year old LinkedIn account is more valuable than compromising one at time 0 the way we currently have designed these schemes is users have to be the same level of

vigilance all the way across so from registration attendings down the line they still have to be scrutinizing the site and we know that their tolerance to changes becomes heightened as it goes on so like if something changed they don't care they just like login yeah login I don't care like I just have been to the site before so what we want to do is we want to align our authentication schemes with that model and what we've seen from the previous thing that I described is that it starts off yes a registration that's the most risky point but after that this scheme is defending against that and it means that as the value of the asset increases the actual user

scrutiny can decrease they don't they don't need to be worried about changes to the site yeah challenges are that the client needs access to a DNS resolution API when I say client I'm talking about browser extensions mobile device etc these things are coming from a user developer standpoint but they're not available everywhere and they're not available in the mainline you've got to be in like a canary release to ever leaves beta etc we have compromises between usability and secure isolation so in this point I put it inside the browser extension but ideally as I'll show you in a sec I'd like to move this out to a mobile app and the browser extension would just be more of a dumb

client that's just referring on the dns resolution that it got and the token it would see from the server unless the mobile device do the verification of that so it just kind of got a few layers to it user adoption obviously this is not going to work in systems where users have not accepted you didn't see a teepee or push-based 2fa so I don't know how to solve those problems because those people don't want to use these things yet so yeah future directions there's an app called free OTP that Red Hat does if anyone's from Red Hat after that I've submitted some pull requests for like backfilling of tests is that you I know is you anyway so I've submitted some

pull requests for tests backfilling for that because I really like the app and I like it that Google Authenticator is not a public free open-source app anymore they private sourced it after a certain point so you know it's nice to be able to verify what this code is doing because it's very this scheme is very simple and like we should be able to verify this is the public so I really like this one go check it out the actual app called for your TP which is maintained by Red Hat community so I started extending this and what I'm looking to do here is we have this normal flow this you know browser extension thing where it sends the TOTP

header and then this dotted line here this is using something called firebase Cloud messaging or firebase something it used to be called Google Cloud messaging and it allows you to set up a Google token bound access channel called the device group where your devices can speak between each other and kind of an authenticated manner in terms of they they have a channel to speak to each other essentially and so in previous projects I've done some work around that so it seemed like an ideal fit to combine these two together and all this would do is it would send it to an Android app and then the Android app would do the verification just as it is

in free OTP it would just look to the user as if they go into free OTP they've logged in to the site then free OTP suddenly allows them to click on the thing and then they can copy paste it back into the browser browser and go with the normal flow so as far as the user is concerned even though this looks convoluted to us as developers or security people they don't see any of this because this is all happening on the the back channel via the cloud base firebase cloud messaging and we can also do this similar thing with push based and what I'm calling this is a reverse push so normally so normally with with

push based we do this login and then the server would send the push request and then we have this approve or decline option but instead what I've done here is normal flow that we discussed earlier we send it over firebase cloud messaging and then all we do is we pop up and approve decline and then if the user approves it we do a reverse push and this could be integrity checked with something like an app ID or some sort of signature the other server knows about and then in this case we've protected from an out-of-band approve or decline issue with push-based because obviously if you try to compromise this in a normal push base scenario some user could just get sent

and approve or decline and they might just hit approve you might get lucky right in this scheme there's no way for them to prove because approve decline will become available until it's received this deadline here and that's it

any questions can help myself this guy this guy right here alright so there's this looks great there's a lot that's very reminiscent here of the TGT acquisition in Kerberos which has been around for 30 years RFC 1510 defines the a s wreck and a scrap process which is very similar to the flow here might be worth looking at the lessons learned in the 4200 series around DNS resolution around the use of preauth to prevent replay attacks and see if that applies here just to strengthen this this protocol is here to finding it here us excellent nothing in that same vein there it could even be valuable to consider using the existing spawn a go mechanisms and the browsers

and extending the HTTP negotiating header instead of creating something custom so just something to think about I could see where this could very well fit in no I can't exchange details with you afterwards yeah okay so it's curious how much you've looked into applying this to like some of the newer like to FA scheme to stuff like that II use certificate based OTP as opposed like TOTP I haven't looked in certificate-based have mostly just focused on counter base TPS and push base because those are the things that I encountered in the user space law I wasn't focus on enterprise great solutions because my angle of interest is consumers might user user level and I would assume I don't know enough about

this but I would assume that the certificate based ones were more enterprise related and through that thing I'd consider that securities to be proprietary right yeah no I should look into that that's great thank you all right I think that's everybody thank you so much see you in a bit [Applause]