PW - Password Alert by Google - Drew Hintz

okay so here Google and La project for basic idea but I can tell you this is one project I really want it and I didn't to do that I don't remember that but I might have forgot do this specific for because I think the IDE concepts of this is really really good I wanted this and I'm really happy to through great thank you all right um so to start off you'll be talking about password alert is sort of an anti-fishing tool um I'll give a quick overview of sort of passord fishing just so we don't leave anyone behind talk about how the tool Works talk about some of the security challenges we had with it and then talk

about some of the effects afterwards sort of How It's been useful um so first the sort of initial premise is that as sort of passwords and security people we really make sort of these unreasonable demands on users uh there's this complicated story especially in Enterprises of where should you actually type your pass um and that turns out to be a really complicated question and we sort of expect users to actually in you know there's the obvious main login page which is great but what about some internal corporate Oracle server that verifies your password using ldap after the user enters it like is that okay or not uh and that's a really good question and similar with like third party vendor

sites and to expect users to actually make these decisions every day when you're using it is not a great idea um similarly we're sort of expecting users in web mail and webbased authentication to understand the format of domain names which is kind of complicated you know the top one to to us that's pretty obvious that's the right one and the second one is pretty obvious it's the wrong one but it's just subtle things that make it different you know dots instead of dashes or the order of words and things like that and it's really unreasonable demand that users actually understand how Dom format and to make that correct decision every single time and then along with this where it's okay

to Ty your password is the concept of password reuse that expect users at 50 different unit passwords which doesn't scale unless you're using a password manager or something um so a quick overview what password fishing is you know it's basically just anytime an attacker tricks a Target into typing their password or giving it to them um and a simple example is you know attor emails a link uh and the email might say Hey you know here's a Google Drive attachment I shared you click on this link in order to view it user clicks on the link it doesn't go to Google instead it goes evite.com and it says hey give me your Google password or your Hotmail

password your Yahoo password or if you want to see this document user goes and types in their password and that the attacker has in his access to their data um it's a super simple as hack you know you basically just go to legitimate login page file save as modify the place it's posting the form and these hacker has access to it uh this is super common you know all sticks are pretty much made up but some large majority of account compromises are due to this pretty straightforward simple fishing nothing magical or really interesting um so how can we actually protect against password fishing um initially there's sort of this idea of well in addition of password we should

have some other Factor um some two-step verification like maybe it's RSA secure ID or maybe it's hotp or top from authenticator so that after you Pi your password will'll ask for this code but of course the attackers can just ask for that code as well and then use it to authenticate we see a lot of ATT do this like seran electronic Army and other people um another idea that we have is with things like Google safe browsing where we crawl a lot of the internet and we analyze pages to see if it looks like a fake login page and if so uh Chrome or Firefox will display a big morning and say hey please don't go here and this

works great for sort of large scale fishing sites that are some for thousands of people it also works great if you PRN like to a login page or major Banks websites um it doesn't work as well for say your company's own login page looks different or sort of targeted sites that maybe Google hasn't calleded that are sent out to like you know tens of people so the real solution to all this application is to have this uh you know Hardware crypto authentication last You released something like security key uh there's similar sort of smart card solutions that have been on the market for a long time and essentially this is just you know a hardware device that you

put in the USB slot and it does the authentication with the server it verifies the server is going says it is it only attachs to the proper servers that you are who you say you are and this way you take that credential out of the user's hands and only give it to the proper server um this requires some hardware and things like that and so about four or five years a go Google we were sort of in between these two stages uh we had two-step verification with you know otps that people had to enter but we did not yet have this Hardware crypto authentication security key based thing uh so I created a tool to sort of bridge

the gap between the two before we had security Keys rolled out to everyone and so the idea with password alert is it relies on the core uh fact of fishing that a Target becomes a victim when they type their password into the wrong website um when they get that you know fishing website they put their password in and they don't realize it's not the real login page um so similar to a spell checker password will detect whenever the user types their password and whenever it detects the protect your password it checks the URL and says hey is this actually the vision their website or not and if it's the wrong place then it goes out and takes

action so sort of a quick overview of sort of the workflow here this password learns an excep that sits there and learns about your password whenever you successfully authenticate to Google then it once it learns about it saves a reduce bit salted hash um in Chrome's local storage and from then on it can compare whatever you're typing to see if it the most recent keystrokes hashed the value that it has saved and if it does then it knows that you type your password um and then it can trigger an alert so if you're a consumer normal user using Gmail or something then it could display an alert similar to this it says hey you just typed your Gmail

password on a non-google login page maybe you want to go ahead and change your password before the attacker has a chance to use it maybe you want to ignore it because you're okay sharing passwords with you know Facebook or some other major site that you INSP to secure um and so one thing you might notice is that it's now doing a hash every time you type your anytime you type a keyst anytime you press a button in your keyboard and so this might seem sort of computational intensive about a year ago the idea that we were using password or internally a Google leaked on Hacker News where someone post and said oh my friend at Google they have

this thing and it detects if you type your password in the wrong place um and they're you know stringent about passwords and the first response is oh that seems really unlike you know how would you even do that that's has to be way computation too intensive to actually compute hashes on all the text in Google Documents or something like that I mean it turns out luckily it's not too CPU intensive uh doing the hash takes you know way less than one millisecond maybe like 10th or 100th of a millisec and we haven't seen any sort of noticeable slowdown you know Behavior even on slow Chromebooks and laptops and things like that um so one advantage of this over

things like security key that makes it easy to deploy is you don't actually need Hardware that you have to give out to people you don't actually have to sort of train or educate your users about what's going on you don't have to say oh every time you log in press this different button instead it just detects when something wrong happens then when something wrong happens then it goes ahead and lets the user know it lets you know your security team know that sort of thing um so we'll talk a little bit about the Enterprise use case where we have both the Chrome extension and also a server side component um so the Chrome extension we're talking about

that describing the workflow before um you can configure it to in the Enterprise setting to also protect your corporate SSO page like your company's login page um it also that way you can learn about the password to protect your corporate SSO password and it also has some basic HTML checking where it tries to detect in advance that it might be a fake login page which is sort of a side feature of it um in addition you can figure where to send alerts to and these alerts would have things like oh this user type their p people site.com U maybe you want to take action and you can configure this using chromat management to push it out to people in

your Google forwork domain and you can use existing configuration things for your operating systems uh you know like Windows group policy that sort of thing and so the Enterprise server is what perceives alerts from the Chrome extensions uh and so we've released an open source app engine app uh so you would take the source code upload it running yourself an app engine we're also working on a Google hosted solution where you don't have to manage the app app you just log into a web app like you would expect it to uh so if you're interested in that sort of thing go ahead and email me and can add you to the trusted tester uh so you can play

run with it without having to run your own app engine app and similarly you can actually have it report to sort of whatever sem you want it just does an HTTP post um so you could take action or you know log it however you want and so the server has some basic features of if it notices user types are passing the wrong spot it can expire use password to force them to change it right away um you can email an alert user and or security team to let them know what's going on and the admins can also view what alerts have triggered and then also categorize domains so you might say yeah that internal corporate Oracle Financial

server that's our ha to user password so we don't actually want to take any action when a user types their password there so that's sort of the story of how it works um and the basics behind it um so if anyone has any questions about it feel free to interrupt or anything um and then I'll talk a little bit about um sort of the ways that we make it safe so that it doesn't actually uh make the user any less secure um and some things about evasion results as well cool so the first sort of tenant is that the password data is only kept local uh you take a sha one her machine salted only only store 37 bits of the

the shaw one hash and this hash is never sent anywhere you know in the Enterprise case we sometimes send reports about misuse of it but it only includes like the username and that the URL they use it on but do not include any of the you know hash data or anything like that and in the non-enterprise case you know the normal consumer use case you just install it for your Gmail account uh no data is ever sent from your machine about what websit you type it on or anything like that and this password hash is stored in Chrome's local storage um the local storage in Chrome is isolated for origin so other extensions cannot see the hash other web pages

cannot see the hash they have separate Origins and this is sort of a similar protection to what you might expect to have with your authentication cookies that you already use to authenticate to web services and So speaking of isolation uh Chrome extensions have this nice uh isolated World policy where content scripts that are running uh don't run in the same origin they sort of run in the same origin as the web page they being injected onto but it's a little bit special and so this isolated World concept allows the content script in this case password alert to inspect in and get data from the web page that you're visiting so we can do things like

get keyboard advans you can see what the HTML looks like however the opposite is not true that web page you're going to does not have any access to the Chrome extensions password alerts sayh or JavaScript that it's running things like that so this is a big security boundary that we rely upon so the password alert can do all this interesting work uh with the malicious web page without sort of exposing anything to malicious web page so you might be thinking well sure you're exposing something and that you're accepting keystrokes you know keyboard events from the's web page uh so when a tax scenario is I'm running a mici's website I'm going to go ahead and

generate a lot of fake keybo events and I'm going to if this password warning shows up if I lose focus or something like that happens so the most we generate thousands of keyboard events trying to basically brof Force the password um so we deal with this to protect against in a few different ways um so the first sort of main defense is we discard keyboard events that look like they're programmatically generated um in chum there's no sort of Surefire way to do this um but thankfully programmatically Genera keyboard events tend to have a few different things set like they don't have the window view set the view set properly to the window uh they don't have a character code set

depending on how you do it and similarly if you try to replay legitimate keyboard events uh the time stamp is not able to be changed so we also throw away time stamps that are not monotonically increasing uh so this is sort of a fragile protection it's pretty core to it um so a colleague implemented this is trusted idea uh which is something that Firefox supports and if a if a keyboard event has the is trusted set true then you know it came from an action keyboard and it was not programmatically generated by JavaScript on the most website um and so this features in Chrome Canary so you can go check it out and play around with it for other things

as well uh it's implemented slightly differently than Firefox um and Firefox is trusted as exposed to even the the Dom of what normal web pages that you visit and this sort of is in a real security feature because other things in that web page can also modify the is trusted value so in Chrome is trusted is only set for Chrome extensions because they're in the isolated world so we can pass the Special Value off to them that cannot be modified by the malicious content on the page so we wanted to make that so that developers not sort to make a mistake there another layer of defense that we have as well as that we R liit

the Q stroke checking so that we limit it to about what a normal user might be typing so in this group for scenario might be sending thousands of keyboard events and once we notice that you're typing you know checking way more than what a user can type then we just start dropping the keyboard events and checking for it and then another thing that we have is this idea of the redu bit hash that I talked about um so you might be wondering why earlier we only save 37 bits of a hash and so the idea here here is that we're intentionally introducing collisions so that if you find a way to brot force the password

either through generating keyboard events or by say stealing the hash off your local file system uh which you're in trouble if the attacker can do that because they could probably just steal your cookies anyways or log in as you or steal your sensitive data and rifle through it um so we intentionally introduce this cision so if they're forcing it they're going to likely find a lot of other passwords that also hash the same value and of course this is really dependent upon your password feature Pap um you know if if you have more than 37 bits of password interv you're going expect other passwords to also hash to the same value so if you have a 10 character randomly generated

password then yeah you're going to have thousands upon thousands of other passwords that hash to it and the attacker is not going to be able to discern which one is actually your password and which one's not and we have to go through and trial them say the the web interface which will be great limited server side however if your password is 1 23456 then sure they going to know that that's your password and they're going to notice the Collision right away and tell what it is and so this is sort of a balancing if we store too many bits uh then they're not enough collisions if we store too few bits um then there are a lot of false

positives meaning if you're typing normal things that are not your password one of them can happen to Hash think your password um so we settled on 37 bits which equates to about one false positive uh for 20,000 people typing for a year um this is a very sort of rough MTH because people don't actually type randomly and I'm sure they have all sorts of patterns prob the entire PhD dissertations about it um but it sort of worked in practice and it was a rough number to tell whether is should say 37 or 60 or four bits things like that and so all those ideas and attacks I was talking about before are attacks would reduce the security of the user is

actually using it you know so these attack worked then you'd be sort of wor software having an extension installed um so what I'm going to talk about now are sort of evasion techniques which are ways that the M's web page could evade detection by the tool um similar to like an intrusion detection system or an antivirus say ways the malware could avoid detection but you're still sort of no worse off um and this is sort of a category we expect the c mouse game where you'll come up with inovation technique and they'll try to fix it and similarly we'll still detect existing web P fishing web pages that don't use any of these techniques um and I guess it's worth

noting we haven't seen any of these techniques in the wild um and I've been looking as part of my day job where do sort of threat intelligence set stuff uh so one evasion technique is that say every time that you type a key press uh the web page go and open a new tab and switch to that new tab and this exploited the fact that we were saving the keyst strip buffer per Tab and so if there's a new tab Al sudden as a new keystroke up of these keystrokes so we fixed this by instead of doing it per tab doing it per browser and that way you know user is only typing in one browser at a time so

it seems to work pretty well um similar initially we displayed the warning Banner in the actual page in the Dom because it was nice for the user you don't get a new tab or something you display it they see what URL they're on things like that but of course the most just then hide the down there uh so we switched in set opening up the warning in a new tab and so this new tab has a separate origin of the the malicious uh malicious page and therefore doesn't have any access to the tab itself and there's bug right now where Native Uris Chrome chromium don't actually get content scripts injected into them um that's something that we're

looking at for excit um and then there's this sort of broad idea of evasion where whoever gets to act first sort of has control over the event um so the malicious page can get the event before we can the verus page can do things like prevent default or stop immediate propagation to prevent that keyboard event from bubbling up the event chain and so in order to deal with this we we change their run ad to be running a document start so that way the content script actually runs before the malicious page is even loaded so the malicious page has not had a chance to actually set up a keyboard of that listener um a sort of more tricky one

was that when you press a key uh on the keyboard it generates a key down event so of press the button down and when you it it generates a key press which is sort of the calculated thing that's actually typed um so one interesting evision technique here is that whenever you whenever the most page and see the key down event then we go ahead and refresh the page the key press event never actually Triggs but now s it's a new view a new page things like that so we had to switch the monitoring both key down and key press so that seems simple uh but the trick there is that key down is not actually expose the character

that was typed um instead it exposed something called the character code which is more like a lower level um abstraction of the keys in the keyboard you know maybe like L is column 12 row two um so it gives you this number and that number is sort of translates into a key but not really um it doesn't take into account internationalization like different keyboard layouts it doesn't take into account caps lock state or shift state so you had to write a library that sort of guess what it thought was the shift State Track caps lock is on or off and things like that so it gets pretty complicated we at least have sort of a rough cut of that

that seems to work most of the time um so that's sort of the of the tax and evasion need is there and so then the main question is is sort of all of this worth it you know does it actually work um so we've been using it for three something years probably four or five years I Google internally on all of our computers and so we've seen some significant things so we've had a big change in user behavior um we've had an 87% reduction in corporate password reuse and by that I mean people that would use their corporate password on other websites like LinkedIn or some vendor website things like that and so when they reuse their password then

notice it and say hey change your password here's an email to explain exactly what happened uh We've also seen a 70% reduction in accidental tank uh by this I mean where a user types their password in to the wrong website even though that's not the correct password you know maybe they're not sure what their password is for this expense reporting system so they go and try their corporate password because why not you know it's a company's sort of website and similarly one of the other things I do work is help manage these internal penetration testing uh tests and it was one of the things that sort of initially spurred me into working on this and making it is that we saw

password fishing as a useful attack that was super simple um and worked in the real world and so with password alert we're able to catch something like 70% of internal fishing pests um that number is basically made up because of course the fishing depends heavily on how you do it if you're targeting Android users versus desktop things you're targeting places where password alert is not running like iOS devices or Android then of course we not going to detect it um but we still saw it catch a lot of them um it stopped a significant attempt at attack a Google uh with password alert and with other detection and monitoring systems also some great analysts were

able to stop an attack on still an attempted attack before it became an incident so that was a big win that made everyone's lives easier and we've also had people that have left Google and gone and implemented it off at other companies as well um for their own corporate infrastructure which is one thing that uh helped us push the idea of releasing it for free and open sourcing it sort of letting everyone use um so if you want try it out there's a link there um we have our it's all open source on GitHub as well so you can go check out the code uh we're happy to get contributions um one of the earlier

speaker scoobs has contributed to it as well so really grateful for his contributions and of course for any contributions that anyone else wants to make as well um so does anyone have any questions or anything we're wondering about how so the question is how does it work with password managers um so in general it doesn't really um so they don't sort of conflict um but the nice thing is with the password manager is that it makes the decision for you so the password manager is only going to put your password in when it's actually the real website so that's sort of another nice way of taking the decision out of the user's hands for where to

type their

password since you're using is trusted how does this work with VPN software or remote desktops example um I don't think it should really the is trusted um so I think that's still per browser so it's still coming from the page that you're going on to and the content script is being loaded directly into that page so I think regardless they do it I think it should still work um in the is trusted we're not actually using it yet because it's still in Chrome Canary uh but once Chrome Canary goes to stable then we'll start using it in the case of the password managers where said it doesn't work with now but the good up and get up is there any

reason you couldn't integrated in the way that say it work not just on one password but anything your fault uh regardless where it is so it detects on web page like oh this password it's elsewhere invol that's um maybe you should do something about that yeah definitely that would be a great feature the one thing I think would be difficult is having the extension get access to the passwords in your Vault um if you using something like the Chrome password manager I do not think it has access to it and I think in cases like last pass it's also running as an extension it stores the data in the extension so the extension would not have access to it

unless they implemented some sort of API that allowed this particular extension to get access to it um but I could be wrong not actually sure uh that also would not be very easy to do in one password simply because again the browser extension doesn't have access to [Music] uh so for the the trunet has is 37 bits and I think it could definitely for more or fewer have you actually done any sort of empirical analysis where you reforced your trated hates to find what the cisions look like and then figure out you know maybe a human being look for say 200 Collision reps too many can you pick out real pass through out 200 collisions 300 collisions or 50

collisions like have you actually done any sort of real analysis here to figure out 37 bits is the right choice May 40 or 32 100 right soical and real analysis might be a phrase um we've done some sort of weak anecdotal testing of that um but sort of the reason we didn't go further is it really depends on the strength of your password so some people like you know security team type people choose really random passwords that are hard to distinguish that are long and you know with the 12 character password you all of a sudden get so many collisions it's in feasible for human to look at it and you can do other analysis

um and a lot of people choose really poor passwords as I'm sure everyone knows here um and those are really easy to spot um so yeah the number 37 is very sort of fuzzy you know 36 or 38 or 40 would totally be fine as well um we had to choose some number in that

[Music] range would there be any reason why uh you couldn't set it as a user assignable one like maybe 37 is the default but if they really like it for some specific unknown reason they could set it higher or lower or would that really Clash the image of yeah in general that should be fine um basically right now it has zero settings for the consumer side um so we I try to go with that approach of not actually requiring any configuration you just install it and it just works um without the user having to do anything um so you certainly could and the source code is there to change it so if someone did have a reason it'd be fine to change

as well [Music]

so there might be something that you go into it that allows for if it's the first 30 second bits and we're ignoring rapid keystrokes wouldn't it be possible to inject a series of Rapid keystrokes and make it ignore the user's input sure um but that would still require you to have some way to inject key stps um which with the is trust will be sort of a hard security boundary and now we have this sort of softer security boundary where it's not possible to inject he strs um but certainly if you find a way to De keystrokes you could hit that rate limit and then it would ignore it um if you had a way around the

first of perion there

certainly uh do you get any complaints from users that they say this alerts every time they try to type name their [Laughter] dog gotcha so in fact so every email that got sent out um lots and lot of them uh when people respond I reply to them as well so it has provided really interesting insight into users and what they think the main names are and what they're using their passwords and there were definitely was at least one case where the user said oh he typing X where X is some field that you would fill out normally and it alerted and they said well because that's my password and yeah you know it's just an example you have

chosen something sort of equally poor to their dog's name um as their password and when it types in alerted yeah um but in general those complaints are sort of good and provides an opportunity to educate the user about you know oh if your password is just if you're randomly typing it into email documents or whatever you probably want to get a better password and similarly whenever they say like oh I really thought this is a Google login page there was a big Google logo at the top um then we have the chance to educate them about well look at the URL and actually maybe check the URL when you're typing it in um because that's sort of what we care

about or when they type it in some third party website they say well these are part for Works my password it provs a nice opportunity to to send them an email and say well we still don't want you using the password then so yeah I've heard all sorts of things from users all sorts of angry responses about what they were doing but in general it seems to to work perhaps a silly question for me but I'm you know um there's lot of research shown that people do not change default subjects in in most software uh that also basically that in many many cases don't want store parts we don't know about what would be the benefits and what

would essentially eventually drawbacks of this direct yes that's a great question it's something we've been talking with the chome te about um and sort of the one of the advantages we have now is when a user does intentionally install it they sort of know what they're getting into they sort of expect that when they reuse their password somewhere that they're going to get a warning and if it's directly built in a chrome by default users would be pretty surprised um and in fact our initial sort of Direction was to go and prevent anyone from typing their Gmail password into any other website um and of course all the people that actually have users and talk with

users said well that's totally infusing you know everyone will stop using it and it shows out that's pretty much true um which is why we've sort of lean towards the sort of corporate use case as well internally um but so you could have some sort of optim all and that might have a slightly lower friction than installing an extension where the extension says oh it's going to have access to all of your you know web page events and things like that um if was just an option someone to check it would be easier to sort of Get Around The Invasion things when we're talking with the Chrome team and it turns out sort of it's easy to write a

Chrome extension it's much harder to sort of change the UI in Chrome and change the password manager that sort of thing as well um it takes a lot more work okay last so this is sort of a non- question which is unusual for me but uh um the average user has no understanding of one way function no understanding of of hashing no understanding of of hash collisions truncated hashes anything about that so if you want to implement this sort of uh globally you'd have to avoid the issue of oh my God Google is watching everything that I type which is sort of true um but requires um some special marketing to describe how this this works to a user so that they

understand why it's safe even though everyone in this room already understands why it's safe um so have you guys thought about that have you guys figured out like how you're going to Market it how you going to describe gaps users if you want to do a worldwide perent sure so somewhat surprisingly that hasn't really been a concern um users have not sort of complained about the idea of sort of watching what they're doing or anything like that and I think a lot of that is attributed to being users intentionally installing inspecting this behavior um so people seem to either not understand or not care um about it that hasn't really been a concern um internally when we deployed

it in the corporate there were a lot of discuss questions around privacy and people not necessarily KN what it does but I think that a big difference because it was pushed out to employees automatically and they didn't sort of popped into it and they didn't sort of choose to do it um so there were definitely more discussions there in cently okay well