Cryptography Pitfalls

all right everybody we're going to get started with our 225 presentation go ahead and grab a seat uh my name is John Zola if you guys haven't seen me earlier thanks for coming out this is really it's turning into a really great event so thanks everyone for making this so such a great event uh I'm going to be introducing John Downey so John Downey is the security lead at brain tree which I'll tell you a little bit about um brain tree helps businesses accept payments online in development tools uh with great development tools and first class first class support um one inter in note about him is what he likes to do in his free time is contribute to open

source projects and he helps high schoolers build robots so that's that's pretty cool and I'm really excited about this talk I hope you guys are too so I'm going to pass it over to John with his talk about crypto pitfalls thanks [Music] [Applause] Sean all right so I want to take a second to kind of lay out why I've been giving why I like giving this talk and kind of what the whole purpose is here um so I know you know you're bside so there you have an obvious Buy in or interest in security and uh what I've been finding as I go around is that I keep seeing developers and even security people in some instances make the same

mistakes over and over with crypto uh both in the news and uh in the organizations that I've worked with uh and so this is really more of a cautionary tale uh I personally love hearing stories about failure uh because I think those are the most fascinating stories and you can learn the most from them and what I want is this talk to be grounded in real events these are all real examples I try to give uh in most cases of like how it actually failed uh and what what ended up happening when it did fail uh my goal here is uh for a lot of us you know hey we're security people uh but we may not be crypto security

people and it's very easy to get in over your head so let you know knowing when you're in over your head and knowing when to get professional help is very important so with that I'll start the talk uh as John mentioned uh so I'm the security lead at brain tree uh brain tree helps businesses accept payments online businesses like GitHub and Uber and Airbnb uh so as you can imagine deal a lot with crypto a lot with security uh something you may not know about brain tree uh two and a half years ago we were acquired by PayPal uh so as part of PayPal if you've ever worked with for a very large or a publicly traded company

you'll recognize this statement these are my views not that of my company yeah all right moving on uh now that that's how the way so I want to start with a general overview of like what is modern crypto what are we trying to get out of this uh so with in cryptography uh in the modern sense we want we can try to get three things out of it the first one's confidentiality uh so this is keeping something secret uh if I want to send something across the internet uh like my credit card number I want to make sure that it's it remains secret uh between me and the person who's going to receive it that no one in

the middle who intercepts should be able to read it the next thing is authentication uh we also often call this Integrity protection and what that means is uh when I send a message no one in the middle should be able to modify it without that being detected in some way and then the last one's identification we often combine this with the previous one uh this is knowing who sent the message uh so you know when I go and buy something on Amazon I want to know that I'm talking to Amazon uh so we often see this uh in the form of digital signatures and that we'll say uh you know John wrote you this message and

it hasn't been modified since John wrote it modern cryptography is a rigorous science it's based on uh largely on hard math problems uh so for example RSA is based on the problem that breaking down a very large number into its Bas primes is something that we know is incredibly hard uh you know that's the factoring problem and what we're doing is were betting on no major advances in either math or or Computing so we know that RSA is very hard on classical computers uh there's a whole subsection to be talked about for quantum computers which you can go read about online because it's very fascinating uh crypto like any science should be peer-reviewed uh so we often

hear this in the kind of the you know war cry of don't don't design your own crypto don't Implement your own crypto and I think we've largely we've done a really good job uh in the crypto community and the security community of getting that point across uh generally you know you it's very rare you'll find someone who disagrees with that these days uh this also extends though to things like uh implementing your own crypto from like base Primitives it's very easy to not realize that you're making mistakes uh another thing with peer review uh comes up is kof's principle that is that I should be able to publish everything about my system and how the cryptography is used except

for the keys and it should remain secure uh you know we often think about this as security through obscurity you shouldn't have to obscure the design of your system to keep it secure so cryptography itself is very strong uh the individual Primitives uh you know I wouldn't expect to to see them break anytime soon I don't you know I don't expect to wake up tomorrow and have read the headline AES itself or RSA itself is totally broken uh I do expect however to wake up and be like the way TLS uses RSA and AES is totally broken in like some subtle way on these systems like that that that would make sense to me it's because it's often the way we

combine these systems it's the seams that end up getting attacked and that's really not any different from many other areas in security we go after the seams where the systems are often the weakest so I would like a chance to read this quote to you because I think it's really important and kind of sums up what I mean this is from the book cryptography engineering you've probably seen the door to a bank vault at least in the movies you know 10-in thick hardened steel with huge bolts to lock it in place it certainly looks impressive we often find the digital equivalent of such a vault door installed in a tent the people standing around it are aring over how thick the

door should be rather than spending their time looking at the tent so what you know what I kind of take from this and what this means is that you know you'll sometimes you'll get into you'll find two two people will be in the argument of like it should be 128bit key No it should be a 256bit key uh and they're arguing about this aspect of a system but they're not you know ignoring the obvious like SQL injection or other you know kind of attacks because you know it can be fun to argue about those things uh but you have to make sure that you're not installing your bank vault door on a tent so if you if you take nothing away

from this whole thing uh this slide I think is the most important for practical advice uh everybody you know all these systems have make these mistakes uh but in general what you know you would recommend is hey if someone comes to you and you're like we need to protect data in transit so that's data going across a network uh use TLS we we used to call it SSL or use SSH or IPC or VPN use some known technology don't go and you know be like ah let's go you know invent a new network Transit technology for data at rest uh my General recommendation is use gpg uh if so data at rest means like data sitting

on disc data sitting on S3 or other cloud service provider uh if you can't fit the your model on one of these two try to rework it until you can because it'll make your life a lot easier uh the next thing uh I want to mention is to avoid low-level libraries these are libraries like just open sell P crypto bouncy castle uh the reason is is I often describe uh these L libraries as if you're giving a group of developers a bucket full of razor blades and you're asking them to make a saw you know if you're someone is going to hurt themselves and it's not you know it's we can avoid it it shouldn't happen uh

highle libraries something like salt or lib sodium which has bindings to C Ruby and other things or something like kizar um which is from Google and uh python Java I think they even now have C++ uh these highle libraries help help reduce the mistakes taking away a lot of the seams you don't get to make as many choices uh and that's often actually a good thing you you know choice isn't always great in crypto so these help take away some of the choices uh and protect you along the way so I did talk about pit I did promise pitfalls um so let's talk about those uh the first place talk about is random number generators uh Randomness

is a core part of any crypto system uh we use it for encryption keys and session tokens uh and password reset tokens so if we're not getting good random data uh often times that could be a very big problem and uh so our first Pitfall in this category not using a cryptographically strong random number generator there's a paper published uh used Nix a few years ago called I forgot your password Randomness attacks against PHP applications and what they did is they were uh they surveyed and kind of Dig Dug into a PHP application that was using a not crypto strong random number generator they were just using the built-in mercine twister uh generator uh and they were using that to generate

password reset tokens and so with a little bit investigation and digging they were able to analyze the system such that they could they could predict correctly the password reset token that was going to be emailed to the user without you know without getting it and therefore they could reset the user's password and uh so this is uh kind of an example related to that the data on the left is from PHP some ancient version running on windows so it's kind of hamstrung into its worst case and then the data on the right is uh from an actual random number generator that you know correctly strong and what if you're at the right angle which I am not so I

hope you are uh what you see is the data on the left has a kind of a period it has a little bit of waves in it and that is the exact opposite of what you want in your random number generator you don't want any kind of pattern at all so the next one using a broken random number generator uh since we're in the security Community we probably all hopefully uh remember the debing uh the debing issue a few years ago if that predates your entry into the industry I'll talk about a little bit here uh what happened was this line of code was commented out of op SSL only in Debian uh so open SSL Upstream didn't comment

it out but uh deian is the base system for a lot of linuxes these days so this was copied subsequently into a buntu and a few others it was commented out in 2006 uh but it was not discovered until 2008 uh and for two years the random number generator in base uh in open C was broken on the on deian and this had a lot of issues uh so all the SSL keys and the SSH keys were broken for those two years and they had to be completely thrown away and regenerated and what this kind of goes to show is bad crypto looks a lot like good crypto and it's very easy to get fooled there so the

commit message for this uh the committer was don't add uninitialized data to the random number generator this stops Val Grind from giving error messages and unrelated code so if you're not familiar Val grind is a uh utility to help analyze memory you uh like memory leaks and memory usage and C programs they were essentially doing this to stop like a warning of in val grind uh and the the sad thing is they ran this by the op SSL mailing list and no one yelled like oh my gosh stop it don't do that I went back and did some research here's that line today uh so is this is one way to stop people from commenting

it out there there's giant warnings all around that Doom will rain down if you do if you touch it but Dean was not the only system to have issues with random number generator uh there was one on Android a few years ago uh where people they found out that because their Bitcoin was were being stolen people were using Bitcoin applications digital Wallets on Android devices and what what was discovered is that Android was shipping with a broken random number generator in its core OS uh and this took uh quite a bit of undertaking for Google to fix another one uh this is from uh very late last year Juniper uh it was discovered had a dual EC which is a

random number generator with uh questionable provenance uh that had been inserted in there and there were constants in there that no one could really explain where they came from and so that raised a lot of questions for Juniper uh as to why they stopped using a good random number generator and started using this dual EC uh especially because we've known since 2007 that dual EC is not exactly fast and it also has a possibility that it could be easily back doored this presentation was uh from 2007 at a crypto conference uh and this is one from last year if you were following FreeBSD current uh they were updating the random number generator in FreeBSD uh to follow a stronger model

and they accidentally broke it for four months uh fortunately this never made it into a release version but if you were running on current for four months your random number Jer and your operating system was broken and then uh lastly in this category I want to talk about uh not using random data when it's required so uh in the PS3 they were using this algorithm called ecdsa which is the elliptic curve digital signature algorithm uh you don't need to know the the details of it but you do need to know that elliptic curve DSA much like DSA requires a parameter uh that has to be uniformly random for every single signature uh so you know you would

expect oh all sources from a crypto strong random number generator but I believe in this case Sony was had a constant they had hardcoded in the in the signing code and this allowed the through some really fun math uh the attackers to recover Sony's signing key so they were able to sign arbitrary images to put onto the PS3 I think in this case they used it to load homebrew software so uh General recommendations out of this use a crypt strong random generator if you're on Unix uh or Unix like system read from Dev random there is some controversy about this that's uh kind of slowly going away uh if you aren't familiar with it I wouldn't worry

about getting familiar with it if you are familiar with it we can talk tonight at the Afterparty if you want to argue uh Windows there's random number generator and net uh and there's cryp gen random for those who are on a Windows side of the house next up hash functions so uh hash functions these are often called fingerprints or they're kind of one way uh the reason we think of them as fingerprints is uh just like ideally no two people have the same fingerprint no two inputs to a hash function should yield the same output in an ideal world and they shouldn't be reversible meaning if I just give you a fingerprint off of a glass or something without access to a

fingerprint database you shouldn't be able to tell me who that belongs to uh and with with hash functions there are a couple pitfalls the first one using uh weak and old algorithms uh so this was in 2008 uh md5 considered harmful which was one of the first considered harmful uh the and this this case they used a bunch of I I believe it was PS3s to generate a hash Collision in a uh against a certificate Authority that was still issuing certificates uh with md5 so they were actually able to generate a custom certificate that had the same hash or you know the same digital signature as a legitimate one and they you know therefore got

themselves a CA out of it uh so this was this was the the death nail for md5 and the ca uh system they had people basically told them hey you need to get rid of this stop doing this uh but they kind of waited until this happened before they were like oh yeah we really need to get rid of this uh this was the headline out of after flame so flame was one of those um Industrial Systems malware that came out I think it was an Uranian centrifuge that was discovered on and uh this the the kind of outcome of this was they discovered that there were previously unknown attacks against md5 used in flame to get it by Windows update to

like make it appear as if it was legitimate software uh and this kind of goes to show you it's like oh there must be some worldclass intelligence agency that was involved in this because Academia had no idea this attack was possible and this is a very recent one there are free start collisions in full sha one this has kind of helped Shuffle the ca system away from Sha one and certificates you know we've moved past 75 onto sha one p and now we're moving past sha one onto sha 256 uh but the ca industry is still very slow on this uh for a lot of reasons but this paper is kind of helping move that

conversation forward uh this one's just a fun one I like to talk about uh this is the logo for us cyber command uh they apparently really like hash functions if you're close enough you can see on the inner ring there is some letters and numbers I'll blow it up for you this uh and so it's like what is this uh turns out this is a hash digest uh so this is an md5 sum of their mission statement uh I don't know why this was many years after they probably should have been using md5 uh but yeah so crypto is a design aesthetic too uh the next thing misunderstanding what a check sum is uh so this is a

directory that you could have pulled off like an FTP server whatever uh and this is all fine and good but what the misunderstanding is sometimes is here is that folks will download the Sha one sums or sha 2 to six sums file and they'll compare it against their download file and they go ah this file you know hasn't contained any modifications what it really is showing is that you didn't it didn't get corrupted during the download because any attacker who could replace one of these files could just as easily replace the the check sums file because there's no additional like gpg signature on it or something uh so that that's just something uh occasionally I'll see folks

kind of still make that leap mistakenly and then the last one I want to talk about here is length extension attex uh but before we can do do that uh I have to talk about what they're what they're actually going for here which is something called a message authentication code so a message authentication code is kind of a class of functions in cryptography uh that takes a key or shared secret and a value uh and returns something we call a tag or an authenticator that represents the integrity and um ideally what this shows is that if I send a message across the wire uh anyone in the middle who doesn't have this key uh in modify the message

this the outcome of this tag will will kind of show if they've modified it because the tag will be different and only two people who share the key can kind of validate the tag appropriately and create new ones so so this is great uh and a naive approach would be to create it just like this so uh we'll take the key and we'll concatenate it with the value and we'll run it through shot 256 so the the problem here is that shot 256 like almost all the hash functions we use use besides some of the newer ones have a have a construction where they're vulnerable to something called a length extension attack this is just

having the basis of how they're designed so uh here's the example in code I take my secret and my value and I concatenate it uh and that's my signature and what this allows an attacker to do is without knowing the secret and without knowing the or and uh without really even knowing the initial value they can um put arbitrary additional data at the end if they can get to kind of do the thing so this you know here it's like buy 10 units at $1 and has like actually make that zero you can like change the semantic meaning of the value you're trying to Hash uh and this is once again without knowing the secret so what should have been done

here is they should have used a function like hmac or another secure Mac function uh and that actually prevents this type of attack uh there are newer hash functions like the Sha 3 competition that explicitly in their design criteria said that you had to defend against this that you couldn't allow this type of attack into your hash function uh just because they know that down the road someone's going to once again forget this and try to design a system like that uh so this isn't like a you know like oh that's cool this is a practical attack uh it was used on flickers API uh a couple years ago and so they've remediated this uh this is from this

year though Visa released a new payments API and in it they they were doing the exact same thing key concatenated with data uh and so in their documentation that of a just relased service fortunately they they have now since fixed this but that kind of goes to show you that like we are doomed to repeat a lot of these same mistakes if we're not Vigilant about them so use shots 56 if you need a hash function or check some uh use hmac version of that if you want if you want an HM or a Mac or a signature uh stop using md5 um it's very difficult but you should really start to move away from it

uh and don't use shaan in new projects uh that's not a like hey we need to run out and change sh one today unless your your Project's using it for Collision resistance then you should probably move a little bit faster because these things take a really long time to migrate away from all right so no crypto pitfalls talk is complete without talking about password storage uh briefly I want to talk about hey we've had a lot of breaches uh so this was the original LinkedIn but it turned out it wasn't 8 million it was 117 million uh and then FM Yahoo Dropbox eBay slack and Myspace so uh uh and then there there are unconfirmed reports about Twitter as

well but I didn't want to put those in here since they weren't confirmed uh so we as an industry we know that these password databases are getting out uh and fortunately most of them don't do this some of them did do this so uh a naive way to store a password is well I guess the most naive way is to just store the password which some systems still do uh in you know just the plain password uh but the IDE of approach is to uh do the Sha one of the password this does have a positive it's a one-way value it can be used for verification uh but you know that's really it's only benefit uh so then you know the the

architect will say ah we should salt our passwords uh and so they'll do a salt of the you know shaan salt plus password and so now we're catching up to like where Unix was in like the late 70s early 80s uh with this system uh and so this this also has another benefit it's randomized it can largely defeat these pre-computed tables the rainbow tables uh and it forces attackers to focus on one password uh the problem is these hash functions are incredibly fast because that's their design they're meant to be fast because you want your TLS connection to be fast so what we actually want one is they can be adaptively slowed down um and so those are called adaptive hashing

functions there are a bunch of them out there I honestly don't care which one you use as long as you're using one of them and you correctly tune it so that it's as slow as it needs to be so bcrypt scrypt argon 2 PB kdf argon 2 is like the new hotness on the street uh because it won the password hashing competition uh so my recommendations delegate your authentication if possible uh Facebook Twitter Google GitHub they all allow you to delegate authentication to them and uh if if I need if I want to comment on your blog I don't think I need to give you a username and password to comment on the blog you should

delegate your authentication there's no reason for you to have passwords uh and then uh otherwise if you have a system where delegation doesn't really make sense uh store oneway verifiers using one of those algorithms so I know some of you out there are thinking well I know we have a system that uses sha one with assault what are we going to do uh you know in the you know it's just inevitable like we we wrote code before 2010 like that code stor in production there are still systems out there like that uh so it's okay you can fix it I promise uh so uh my recommended way to fix it uh I'll present it uh

generally uh what people do here is you know so say you have a password hash function uh that's just the salt concatenator or the password like shot one so the the naive and kind of common approaches wait for the user to log in and then we'll like silently update their hash in the in the background for them and that's great but have you ever looked at the statistics about how many users actually log in and when was the last time they logged in and what you'll find is there's an incredibly long tail uh in most systems I've seen it's I would be surprised if more than 50% had logged in in the last month or so uh so don't wait

uh my recommendation is if you have a reasonable system that wasn't as incredibly bad as something like descript which uh if you don't remember descript Cuts passwords off at eight characters uh so just wrap bcrypt around the existing system and then your system Becomes bcrypt of shaan and upgrade all your passwords in place done because users who don't log into your system deserve password security as well uh so password hash column is now bcrypt of sha one of salta password and as long you know this is is generally reasonably fine if you want to migrate them to just B Crypt as they log in that's fine but at least your users who don't log in will be in a better

position next let's talk about some safer pitfalls once again old week algorithms kind of rears its ugly head uh so this is a paper from a while ago uh this I think this research was sponsored by the eff back in the early or like the late mid to late 90s breaking ciphers with Copa Cabana this was uh one of the first like hey can we use fpgas uh in like custom built Hardware to break uh systems so this broke Dez the you know original de not triple Dez uh and the numbers in this are fascinating because you could do it for far cheaper today on Amazon uh next one so we've known for a very long time that rc4 was not a great

Cipher uh there are weaknesses in the key scheduling there are biases in the output uh and yet we still it's still like a very well you know kind of very widely used Cipher on the internet so then there's uh there's a vulnerability in a movement called rc4 no more trying to get uh systems to move away from rc4 uh because it still is available in TLS today uh so if you have a block Cipher using ECB or electronic codebook Mo mode to kind of talk about this one we'll do need to do a refresher on what is AES and what are block saers so block ciphers are a pair of functions they take a key and then they take either the

plain text and the cipher text and they give you either the plain text of the cipher text as the output with me so far I hope but the pl text or the input and the output are 128 bit values and I don't know about you but most of my most of my data is more than 16 bytes uh so what do I do the what people generally will come up with is we'll just Loop over it 16 bytes at a time and uh we'll encrypt it that way so this is a formalized mode it is known as electronic code book uh and it's has many problems but one of the main problems that is basically easy to talk

about and easy to show is it allows patterns to show through uh your output and so if your input has any kind of structure you'll see that structure come through in the output so this is the brain tree logo and this is the brain tree logo encrypted uh in ECB mode with as and some random key so uh you may have seen this with the l tux the Linux penguin but it's the same idea what we actually want is the thing at the bottom we want you know it can be look completely no different than noise uh and only with the correct key can you kind of see what the true meaning was like I said there are many

many other issues with ECB mode but this is the one where it's like people can kind of when you visualize it and can see it uh a lot of folks will get it uh not using authenticated encryption so uh this one uh so we've known for a very long time since eurocrypt 2002 VOD pointed out things called padding Oracle attacks uh this paper came out in 2010 these were the folks who did the um the Beast attack on TLS where they actually uh made this practical and then later on uh folks redid it with a different part uh and they made poodle so uh practical attacks that have come out of this this paper uh another one lucky 13 which was

another attack against TLS this is where time code wasn't constant time time so it leaked information and then lastly this one's very recent uh Apple had an issue in iMessages where they weren't using authenticated encryption and we kind of know these days now that remember at the beginning we talked about confidentiality and integrity we know that if you don't provide Integrity you can't guarantee confidentiality so a system has to have both and that's what we mean by authenticated encryption uh so this was the paper that came out of it uh out of John kins dancing on the lip of the volcano chosen Cipher tax against Apple iMessage and you know largely I don't blame the developers you know like we've

kind of as Security Professionals we've given them this world of hurt that they live in like this is the documentation for py Crypt uh the py crypto LI or the python crypto library and like look at all these options we've given them look at like all these things they have to choose and then the you can't see it but uh in this example at the top they're using uh CFB mode which nobody uses like why why is the example in the documentation using an encryption mode that a is an authenticated encryption and B no one uses in Practical systems like we're kind of really just setting Folks up for failure so my recommendations prefer the

Box secret box constructions from sodium uh and salt stop using Dez like really if you have a system that uses Dez you really should as soon as my Talk's done wait as soon as my Talk's done you should probably go to your office and be like what's our plan for migrating away from this very soon like this week uh stop building your own on top of AES if you can stop encrypting without protecting the Integrity so here's my site for anybody who's in an uh regulated industry uh so what if you have to use AES what if your auditor comes to you and says hey you didn't say AES when you're talking about your your encryption scheme uh what's

this thing you're talking about you didn't say the words a uh don't use EC CB mode uh be sure you're using authenticated encryption so GCM is kind of the go-to for authenticated encryption with AES there are other Alternatives though uh verify the tag or the Mac before you decrypt something with GCM a lot of good libraries will do this for you uh and then it's still easy to mess up in a critical way unfortunately talk about some TLS or SSL so hopefully uh most people will have known that we used to call it SSL but then it's been superseded by something called TLS and the SSL itself is no longer in Practical use at least since

poodle a lot of systems may still have it enabled but you shouldn't uh everything should be using TLS now so uh the first thing not verifying the certificate chain or the host name so this is a pretty big one there's a paper a few years ago called the most dangerous code in the world validating SSL certificates and non-browser software and what these researchers did is they kind of did the survey of all these mobile apps and things like that uh to say hey were they doing uh TLS and SSL verification correctly and boy did they find out no uh so outside of browsers most systems weren't doing a very good job uh and so what is involved in

verifying that so the if you're not familiar with the certificate chain it's kind of this thing at the B at the top that I've highlighted here and that's where it you know it says hey I have this certificate for dubdub duub brry payments it's trust by this editor certificate which is trusted by this edor certificate that we have installed in our operating system already um the other problem is the host name verification uh is a it's not built into op SSL so a lot of uh a lot of applications aren't doing it because they thought openness was just doing it for them uh and that's checking that you got the certificate for who you intended

for so the first one's checking that the the math is correct so the certificate chain math is correct the second one is just checking that the string of the domain name is the one you intended to connect to if you don't do the second one uh I could just go get a free certificate from let encrypt present it to you and you're going to think that it's valid because you're not checking that the subject of it is who you're actually intending to connect to so what does that look like uh it looks like passing DK to curl which I honestly have seen in a vendor documentation they're like just pass - K it means like secure

uh or uh this is some PHP code because I'm picking on them uh so if you use Curl uh verify Pier is like hey I want to know who I'm talking to and then verify host is like I want to make sure that they say who they they are who they say they are you have to have both uh in some instances one or more is set to zero so it's not actually doing the verification misconfigured server settings so uh this is the report from SSL Labs the identity of the domain has been blocked out because I didn't want to embarrass them too bad but needless to say this was a government oriented website in the EU uh and they got an F

and there's a Litany of issues with it like using weak Diffy helmet untrusted certificate like a bunch of stuff uh if you haven't already use SSL labs to run it against your your servers it's an incredible Tool uh it will give you a very very good overview of like what you're doing well what you're not doing well and then links to how you can improve it if you're totally lost for where to start Mozilla has released a tool on GitHub called the TLs server settings uh where you basically like I'm using enginex I'm using open SSL here and it just like spits out configuration for you to copy onto your server uh and then the last one using a

broken Library so we all remember heart bed I'm sure a system after this talk is still going to be compromised because no one patched for heart bed uh go to was another one OSX and iOS share some crypto code and that crypto code wasn't validating part of the PS handshake correctly so you could intercept and modify traffic Bound for those devices so ensure you're validating your connections like go and actually check and and like double check uh lean on a framework and Library check that it does the right thing though because sometimes they don't and no one told them uh set up automated test to validate this setting so go to like bad ssl.com uh and

see the examples of all the bad forms of SSL and TLS that they have in there lastly I want to talk about trust uh quick poll how many people have seen this prompt before you know what this is all right now keep your hand up if you validated that that fingerprint before you typed in yes there are honest folks in the audience thank you uh so what this is is uh s SSH has a trust model called tofu Trust on first use and what this means is that SSH is kind of like Hey we're buddies you uh you tell me if this is cool and then I will mathematically check that it's the same always after

that uh hopefully you know I'm sure people have seen this hopefully you didn't just go blow away the entire known host file that's generally the stack Overflow response for like what to do with this uh this is saying hey remember that thing I promised you I would do I'm doing it uh the this mathematically doesn't check out anymore usually this means like someone reinstalled the operating system or something uh so this is a video of me scrolling through all the Mozilla trusted certificates that ship in Firefox uh you're not meant to follow it because there's a lot of them uh so what I ask is like do you trust all these organizations do you trust their hiring

termination practices their audit practices all these things uh I imagine you probably don't there are some organizations in here like uh the Hong Kong post office the Department of Homeland Security Visa uh so while some of them are some of of them are trustworthy organizations I'm sure and you have to trust somebody uh it's always good to like take a step back and think about who do I trust who who in this organization because uh my old list this list I believe is up to date that the old list included organizations that had been breached like diger and that brings me to the last topic of certificate Penning so certificate Penning is a way for you to

kind of narrow down the trust for your application and that allows you to kind of choose my application you know use trusted Roots but we're only going to trust these few uh or you can even go further it's like I'm only going to trust this this key that I know we generated you know ourselves there uh there are multiple ways to do this the the emerging way for web browsers is this public key Penning proposal uh I recommend you go investigate this uh find out if it's appropriate for application the thing about what organizations really trust investigate certificate Penning all right is it over it is over Stephen uh if you want to learn more I highly recommend the

Stanford crypto class on corera uh they I don't believe there's a currently scheduled session they pop up from time to time there's also a part two to this class that I like to describe as the Bigfoot of corsera classes uh everybody like keeps saying it's coming like I I heard it was coming in the fall uh and then it never happens and then they'll like one time they like sent out a course survey like a pre-course survey for it and then that one away uh it's kind of crazy I'm am looking forward to it though because it was an incredibly good course from Dan Ben uh and then lastly the monosan crypto challenges from crypto Pals this used to be run out

of email they would like email you the set and then you would email it back uh they get very overloaded with email so they set up a self-driven website so these are kind of developer challenges where you actually get to write code to break these crypto algorithms it's really really cool and that is it I have four minutes for questions thank [Applause] [Music] you all right so I have a quick question um earlier in your slides you gave some recommendations and you said sha two yes I was wondering why he didn't say sha three so that's so the I will answer two things because you said something and I wanted to tell people so shot two

applies to a family of functions shot 256 is one of that family why I did not say sha 3 is because it is not although it is standardized uh there there are multiple reasons a you don't find it implemented in a lot of systems yet so you don't find access to it in like the libraries uh and then B There were some like last minute Shenanigans with it between it and nist and the uh other organizations that have people kind of going like hey we had this perfectly good algorithm why did you mess with it at the last second there are other great hashing algorithms out there um Blake 2 and a few like that that were

finalist in the Sha 3 competition uh I personally until we have a reason to switch shot 256 is still a really good choice shot 3 does have like the length extension thing is fixed and a few things like that but honestly the systems I work in we don't have access to it uh unless we add like native extensions or anything so it's like not even surfaced yet they they are and so he says functions are awesome and that that's true and there there's lot of future use of them but uh we have to actually have practical like applicability hey so you talked a lot about the server side can you say quickly like from the browser side or

from the website I know you talked about certificate pinning and trust but what as an user can I do to to kind of protect myself yeah so the question was uh I talked a lot about the server side what about the browser the client side uh so SSL Labs has a client side test too that you can either I think you can either curl it or you can like whatever your system go fetch it and you can hit it with your browser and it'll tell you if it thinks your browser is doing a good job there generally aren't too many knobs in the browsers for you to choose at least for the most part I think the

best uh advice is to keep your browsers up to date so Chrome Firefox both do an excellent job of keeping up to dat and uh Chrome even so much as like when they have issues with certificate authorities they'll push Blacklist out and like you know that's their kind of their big hammer for certificate authorities is like we'll block you which totally cuts off your commercial viability because that's a major [Music] browser this is question do you feel that transport mayor security is is sufficient or with things like sample requests you feel you should be layering like addition okay so the question was do I feel transport layer secur or TLS is sufficient or do you need to layer

additional things on top of it you mentioned samle uh and then XML encryption in the payload uh so for that I have that conversation with a lot with engineers and my organization and I think in each case it comes down to like what's your threat model right is your threat model uh someone will fat finger it and the unencrypted data will get dumped out to logs or Splunk or something you know and then you know then we at least have an encrypted payload there instead of an unencrypted payload uh I think largely the wrapping an encryption around an encryption you that means at some point you don't trust the person unwrapping one of the encryptions

so figure out why you don't trust them and if you still don't trust them that's fine like layer the encryption but it's important to think about it from a real threat perspective who's your favorite RS or a the the question was who is my favorite RS so uh Rees um Samir and Adelman uh I true story I was at the Ral crypto conference I hope no one ever watches this on video I saw Ron reest fall asleep in the front row of the of the thing so he has to be my favorite he's like I am so OG I can fall asleep in the front row of this crypto [Music] conference you mentioned some U fated

off like Facebook go you have any thoughts on ph UTF for UF on on sorry oh on Pho yeah so the question is do I have any thoughts on Pho uh so I I I'm a big fan of phto PayPal my company is also a big proponent of phto uh I'm like I was one of the first people to buy the u2f and like start implementing it I'm actually really sad because I was like I'm going to do a ruby gy that does u2f and I started writing it I got very far but then I got like distracted and then like two Days Later someone pushed a empty gym and claimed the name and I was just

like flipped the table and I was like never mind hopefully they finish it uh but yeah I'm a big fan looking to phto the u2f and the uaf framework those are

cool all right I don't see anymore but I'm also have lights in my eyes so thank [Applause] you