---
title: "Chris and Robert -- Passwords, Identity, and #AppSec"
url: https://appsecpodcast.com/chris-and-robert-passwords-identity-and-appsec/
date: 2017-09-12
duration_seconds: 1926
topics: ["Privacy and Compliance"]
audio: https://www.buzzsprout.com/1730684/episodes/8122708-chris-and-robert-passwords-identity-and-appsec.mp3
transcript: true
---

# Chris and Robert -- Passwords, Identity, and #AppSec

*September 12, 2017 · 32 min*

on [Privacy and Compliance](https://appsecpodcast.com/topics/privacy-and-compliance/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122708-chris-and-robert-passwords-identity-and-appsec.mp3)

## Show notes

Password advice changes as attackers, hardware, and identity standards evolve. Chris and Robert examine how passwords are guessed, cracked, stored, and reused, then compare long-standing habits with updated NIST guidance. They discuss dictionary attacks, hashing, salts, password length, composition rules, password managers, and the risks of knowledge-based questions. The conversation also explores checking proposed passwords against known breach data through Have I Been Pwned and the operational cost of doing that safely. Throughout, they separate user-facing policy from the developer’s responsibility to store and verify credentials correctly. The result is a practical review of why familiar password rules often fail and how modern applications can make authentication both safer and more usable.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Chris Romeo and Robert Hurlbut:  
→ [Chris Romeo on LinkedIn](https://www.linkedin.com/in/chrisromeo-appsec)  
→ [Robert Hurlbut on LinkedIn](https://www.linkedin.com/in/roberthurlbut)

Mentioned in this episode:  
→ [NIST SP 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html)  
→ [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)  
→ [Troy Hunt](https://www.troyhunt.com/)  
→ [Have I Been Pwned](https://haveibeenpwned.com/)  
→ [Enpass](https://www.enpass.io/)

Chapters:  
00:00 Passwords, identity, and application security  
01:30 The reality of hundreds of passwords  
03:21 Hardware advances and password cracking  
05:15 Dictionary attacks  
07:34 Hashing and password storage  
09:28 Cracking weak hashes  
10:48 Knowledge-based questions and social engineering  
13:11 Changes in NIST guidance  
14:36 Supporting long passwords  
16:03 Password managers  
17:42 Evaluating password-manager risk  
19:17 Retiring forced periodic changes  
21:27 Checking passwords against breach data  
23:37 Operational cost and implementation choices  
26:19 Maximum length and denial-of-service concerns  
28:11 Why every password needs a unique salt  
29:43 Slow password hashing  
31:15 Final recommendations

## Transcript

*5,258 words · assemblyai*

**0:05 Chris Romeo:** The Application Security Podcast. Here we go. Hello all, welcome back to another episode of the Application Security Podcast. On this week's episode, Robert and Chris talk about a relatively well-known topic, passwords. They dive into the threats that can occur with passwords and much more involving identity, AppSec, and how passwords interact with both of these. As always, thanks for listening and enjoy. Hey folks, welcome to this episode of the Application Security Podcast, where today Robert and I are going to talk about passwords, identity, and the intersection within the world of application security for passwords. So Robert, what— you know, we've— everybody's got passwords, right? How many passwords do you have? Don't tell me what they are, but how many total passwords do you have in your life?

**1:18 Robert Hurlbut:** Oh, I probably have at least 20, 30, 40. I've lost count, but I'm using a password manager, so it's keeping track of those for me, but I know there's quite a few in there.

**1:30 Chris Romeo:** Yeah, I mean, I actually was teaching a class a couple of weeks ago, and I totaled up the number of passwords that I had stored, and it was something around like 300 or so different passwords for all the different services and things that I use. And so, yeah, I think for our listeners and for everybody out there, as you're thinking about the passwords that are part of your life, you probably have at least 50, maybe 100, maybe more. Some of them may be for accounts that you haven't used in a long time, like your old Yahoo email password that when you swore off Yahoo, maybe you forgot to actually delete the account. So, you've got some other accounts out there. So, Let's talk a little bit about the different threats then. Since we are the Application Security Podcast and we love threat modeling, let's talk about what the threats are from an overall password perspective. So the first one that I was thinking about here, Robert, was this idea that somebody could reverse the passwords that are stored in a database somewhere. So what do you know, what have you heard about this idea of using commercial-grade hardware to actually crack passwords or guess passwords?

**2:40 Robert Hurlbut:** Yeah, I've seen some examples where you can use GPUs that will give you a lot of capability and then hardware to be able to really, really fast trying to crack passwords. And then also being able to go through, if you obtained a password list, to go through and compare to a lot of other things out there to figure out what it is. So, it seems like a lot of options that somebody, if they wanted to, much more so than maybe 10 years ago or 5 years ago in terms of hardware availability.

**3:21 Chris Romeo:** Yeah, Moore's Law that says that processors or whatever are going to get faster over time seems to be consistent with the world of password cracking. And just to kind of lay a little bit more detail around the edges there. When you said GPU, that's— you're talking about a graphical processing unit, right?

**3:42 Robert Hurlbut:** Correct. Yes.

**3:43 Chris Romeo:** Okay. And GPU is the chipset that traditionally draws all the things on your screen and handles kind of the video output on the computer. But what attackers and those who are serious about cracking passwords have figured out is that GPUs are really good at math. They can do a lot of calculations and things per second. So you can use a GPU. And what some of the folks do is they'll actually build a specific piece of hardware, a computer to crack passwords, and they'll put like 8 video cards in it. So they have 8 different GPUs that then they can write software to actually test. And they can use that to try and do this brute force password attack. And so a brute force password attack is just when you have access to— these days you almost have to have access to the password hashes that you've stolen from somewhere or downloaded. And what the brute force attack does is it just goes through and tries every possible password combination from starting with 0 all the way up to 10 digits long or whatever of every possible character combination. And because it can do— it can try those different hashes so— or try the different options so quickly with that high-end hardware, it's possible to guess or brute force passwords, uh, just by going through every possible option. So what about dictionary attacks? How does a dictionary attack play in?

**5:15 Robert Hurlbut:** Well, it turns out that, uh, Most people, or many people, will create their passwords using a word. They want something that they can remember, and so essentially a dictionary attack is going through the dictionary and using those words and combinations of words to try to see if there's a match. I've also heard of attacks using something like Wikipedia and just going through and finding common phrases and try those again against passwords and see if that is a match. Those are some other ways to try to do some brute force attacking and find out. Not just a bunch of combination of letters, but actual words to see if there's a match.

**6:02 Chris Romeo:** I think that that's the biggest threat that passwords in our modern-day era have to consider. But then another threat that's existed since the beginning of computing, or I should say since the beginning of networks, is this idea of a man-in-the-middle threat. And so what we mean there is that if you have— so you have a user that's on their computer or using their browser, and they're communicating with a server. And the time when that password's actually going to be used, what's going to happen is the user's going to open a session to that server. The server's going to say, well, hey, you need to authenticate who you are. And then the user's going to put in their username and password, and then that's going to be sent between their browser and, say, the web application that we're talking about. Man-in-the-middle is the idea that if we don't properly protect that password in transit, that somebody could intercept it, and they could perhaps even take over the session, or they could grab it and get the password just by being somewhere between the legitimate user's browser and the server side. And so, this is something that's fixed with protocols and using good crypto and stuff. It's not as big. I mean, when I got started in security 100 years ago, this was a much bigger challenge because we didn't have crypto. We didn't have good protocols for everything back and forth. But with where we are from a crypto protocol perspective, this really is—

**7:34 Robert Hurlbut:** Yeah.

**7:35 Chris Romeo:** Do you see this as much of a threat these days?

**7:36 Robert Hurlbut:** Not as much, but I still see, for example, if you're in a coffee shop with an open Wi-Fi, there's no password on it at all, and you're connecting to sites that don't have any kind of encryption, HTTPS or anything like that, and logging in, it's open game. That's still there. That hasn't gone away. That type of threat is still there, but overall, like you said, there's a lot of better encryption, cryptography, HTTPS, and stronger certificates, and so on, that try to make this hopefully a thing of the past. Yeah.

**8:20 Chris Romeo:** Then, another potential threat is that an administrator of a production web application could actually steal password hashes directly out of the database. And it's important for folks to realize, we probably should have started with this, when we're talking about password hashes, a good web application is not going to store your password directly as you typed it in. That would be what we would call a bad web application if they just put that password in there with no type of, without running it through any type of a function. Right. Hashing function that's going to modify it and then store the— not store the actual password, but it's going to store the result of that hashing function that's going to scramble it up so that it appears to be kind of scrambled as it's stored. And so the threat that we're talking about here is that an administrator could— an evil administrator could have full access to the password hashes. They could go and grab those hashes, and then they could take them and go back to that original reversing of the passwords, they could actually— because they have some type of heightened access, they could then actually use that to try and crack the passwords.

**9:28 Robert Hurlbut:** Right. So in those cases, what they are doing is, like I said before, with the dictionary attacks or just a collection of words, all they need to do is, if they figured out your algorithm that you are using for hashing those passwords, all they need to do is just hash a bunch of words and compare and see where they get matches. Interestingly enough, some of the hashes unfortunately have been broken, some older ones like MD5 and SHA-1, and even some of those, you can actually put some MD5 and SHA-1 hashes in Google for a search and you may find it, which is really wild. You can get those back, and so it's almost nothing to crack some of the older algorithms for hashes. Those are some things that can happen as well.

**10:19 Chris Romeo:** Yeah, and then the last one that I threw onto our list here was just overall password guessing. And that is kind of more of the human element side of this where people tend to make predictable choices in how they set passwords. And so password guessing is really just the threat that, hey, somebody will profile an individual person and be able to say, you know, if I figure out their birthdate and all their pets' names, I may have a better chance of being able to actually guess their password.

**10:48 Robert Hurlbut:** Yeah. Right, because, well, that's social engineering really, right? So you ask someone, what's your birthday? Do you have a cat? What's his name? Things like that. And it turns out that's what people use for their passwords.

**11:02 Chris Romeo:** Yeah, there's a great Jimmy Kimmel password interview that he actually sent the— kind of a man-on-the-street style interview. He sent somebody out to just talk to different people. and ask them, hey, you know, will you tell me your password? And they're like, oh no, we won't. And they're like, and they're like, well, what do you base your password on? Oh, well, I like to use my birthday and, uh, and my pet's names or something. And then he's like, um, then the person would continue the conversation and 30 seconds later they'd be like, oh hey, when's your birthday? And the person would tell him and they're like, oh, what do you know, do you have a cat? Oh yeah, I have a cat named Fluffy. And so they would just collect all the information and it's, it's funny to watch, but—

**11:42 Robert Hurlbut:** Right.

**11:42 Chris Romeo:** Um, it proves the fact of kind of the human element side of this.

**11:48 Robert Hurlbut:** Right.

**11:48 Chris Romeo:** So, I guess our first phase of this conversation was to talk about what are the threats to passwords. We mentioned reversing those passwords using some solid hardware or even a cloud service that can crack passwords for you. There's the man-in-the-middle problem if the protocols aren't secure. There's an admin just stealing a bunch of hashes. We didn't even talk about the data breach side of where do those hashes come when you revert to be placed into the reversing passwords kind of machine. We talked about password guessing. I guess transitioning, let's now talk a little bit about this new NIST standard. National Institute of Standards and Technology is a group, a part of the US federal government that does a lot of different things, but they do have a cybersecurity function. And what they've done is they've written this, what they call this Digital Identity Guidelines, Authentication and Lifecycle Management. It's called NIST Special Publication 800-63B, not to be confused with A or C in that series. But I had a chance, Robert, to take a look at this, and I see that they're doing some kind of— they're kind of changing the game a little bit on what our common best practices as application security professionals have been for, you know, for as long as I've been doing this. So did you see the same thing?

**13:11 Robert Hurlbut:** I did, yeah. I saw a few things that were interesting, some changes over the years. I mean, there's been a lot of things that we've known about different guidelines, but yeah, they seem to change a few of these.

**13:26 Chris Romeo:** Yeah, so they started with the 8-character minimum. So that was old school, right? We've been recommending 8-character minimums since the dawn of time almost. And what they mean by 8-character minimum, obviously as it sounds, is that You have to ensure that passwords are at least 8 characters long. They also allow a minimum of 6 characters if it's a machine-generated password. And what that means is you have some type of a function where somebody says, hey, choose a password for me, and it gives you a recommendation of random characters or something together. And so I thought that was interesting. I thought 6 characters, if it was machine-generated, seemed a little weak from my perspective.

**14:08 Robert Hurlbut:** Mine too, yeah.

**14:09 Chris Romeo:** So I don't know what led them into that type of direction, but that's the decision they chose to go with.

**14:14 Robert Hurlbut:** Right. Yeah, I mean, the fewer number of characters that you have, then as you mentioned, it's weaker. It gives— it's easier to come up with all the combinations. The longer the password in terms of characters, number of characters, then it's going to take longer to try to figure out what it is.

**14:36 Chris Romeo:** So, but I can get past that. I can move on. So, the next thing that I saw in the standard here is they are extending the maximum length of passwords so that it is a minimum of 64. Because what you see is a lot of sites will say, hey, you have to— your character— your password has to be a minimum of 8 characters, but it only can— the maximum can only be 12 characters. And so, they're saying you have to have a password that's between 8 and 12 characters. So, what the NIST standard is saying When you build an authentication function, ensure that you allow your users to have a— if they want to create a password, make sure that they can, and make it really super long. Like, it has to— your system should support all the way up to 64-character passwords. You could even go further than that. You could say, you know what, I'm going to support 1,024 possible characters as a password if some crazy person wanted to build a— have a password that was that big. But the point is, don't limit the users by saying, hey, you can only have a 10-character password maximum, because that's, you know, why hold back the people who want to be really proactive about setting a good password?

**15:46 Robert Hurlbut:** Right. And also, if you have a password manager, I mean, that sort of thing is definitely feasible, right? You could easily have a 128-character password with a password manager because the password manager is managing that, not you trying to remember all 128 characters for every place that you visit.

**16:03 Chris Romeo:** Yep, definitely. And that's, you know, we mentioned that a little bit in the beginning part, and it's important for folks to know that, you know, there's different password managers out there now. They integrate with your browser. They provide like a client environment where they will securely store passwords that, Either you set yourself, it also has the ability to generate passwords and then store those and then replay them back when it's time for you to authenticate to different web services. And I've become a big proponent of the Enpass, E-N-P-A-S-S. They're not a sponsor or anything, they're just telling you the software I use in my life. And the thing I like about Enpass is that it, It doesn't— it allows me to synchronize the password database that I have amongst devices, but it doesn't do it in their environment, meaning it's not a cloud service they provide. It actually allows me to use a multitude of different ways to synchronize the file, like Dropbox or Google Drive, or there's iCloud's equivalent. So it kind of separates for me. I like it because it separates the function of having a password manager from the storage side. It abstracts the storage of it. And that's the part that I really like about it because like some of the other people that are out there I've used, but they want me to store my password database in their secure cloud service where they store everybody else's. And so if I'm an attacker, I'm going after that. I mean, that's— I mean, imagine if you got into that database, you could own the whole world.

**17:42 Robert Hurlbut:** Right. And there have been some news reports of some password manager companies that have been compromised because of some of those— I think some of those reasons. So yeah, no, it's a good idea to take a look at that particular product. I'm not familiar with it. It's good to know.

**17:58 Chris Romeo:** Yeah. And it's a byproduct of being a security person for a long time. Makes you extremely paranoid, which is good and bad in its own special way. So another thing that I saw in the NIST standard here, no password hints allowed. I don't really see those much anymore, but they did used to exist a lot in the old days where if you entered the password incorrectly, the system would bring up a hint that you had previously set, and some crazy people would actually put their password in that hint.

**18:28 Robert Hurlbut:** Right, right, exactly. I don't remember what it is, but let me put it here so that I'll remember what my password is.

**18:34 Chris Romeo:** Yep, exactly. So the NIST standard is saying don't do that anymore. That's not allowed. Here's the interesting one. The standard actually says no to composition rules, and this is the complex— or complexity rules. And this is the kind of statement that when you go to set a password, it says, well, you have to have, you know, 3 special characters, at least 1 being an asterisk or something else. And so what NIST is saying is that when they did the research and they looked at those complexity rules, And users tend to make bad decisions and then just add one character to be able to deal with those complexity rules. So they're actually saying don't use— that they don't want complexity.

**19:17 Robert Hurlbut:** Interesting. Yeah, I saw that too. And I thought, wow, that's interesting. That's very, very different than what we've been hearing for years.

**19:24 Chris Romeo:** Yeah. And you got to flip it back around on kind of the end user perspective. And we have to take off— we have to put on our end user goggles, I guess. And We have to think about what is the end user actually kind of dealing with here? And are they going to, you know, we as security professionals, we understand the benefits and we use complex passwords because this is what we love already doing this stuff. But the average end user inside of a big company, they're just gonna do whatever they have to do to make their password easy to remember. And so I think it's a very valid approach that NIST is taking.

**20:02 Robert Hurlbut:** Yeah.

**20:03 Chris Romeo:** And I'm actually, I'm actually in agreement with it. I think it's, I think it's okay.

**20:06 Robert Hurlbut:** Yeah, I think so too. I think so too.

**20:09 Chris Romeo:** The next one was this resistance to offline attacks. And so we know that across the, the internet universe, there's been a number of different data breaches. You know, if you're paying attention to the news today, Equifax, and we don't do news, but Equifax just dropped 140— a notice that 143 million Social Security numbers were stolen from their site, some credit card data. So data breach is a big thing that's always happening, and data breaches actually sometimes contain usernames and password hashes for a given site. And so what the NIST guidance is talking about here is that your authentication system should really have some type of a some type of a tie-in to those hashes that have been dumped before. And a perfect authentication system would be able to check the new password that somebody's trying to set against previously known bad passwords that were released in data dumps that attackers are already going to know about and actually tell the user, hey, sorry, you can't use that password. That's a known bad password that's been cracked like crazy. in the public space. So what else do you know about that one, Robert?

**21:27 Robert Hurlbut:** Well, actually, essentially, if you're looking for when someone's trying to enter a password and you say, well, what do I do? How do I know what other passwords are out there being used before? Recently, I know Troy Hunt, who's a security researcher out there, he published a large list of passwords that have been obtained through data breaches. And on his website, troyhunt.com, I believe, He gives some information about how to pull out that database into your own environment, put it into your database so that you can also do a check, and then make it available for production. He gives some examples where some people have done that. You go in as a user, you put in your new password, and then a message comes back to you to say, you can't use that password. It's already been used in a data breach. Please pick another one. I think that's pretty good advice.

**22:22 Chris Romeo:** Yeah.

**22:22 Robert Hurlbut:** I think it's effective, and I think it'll be really helpful for users to— and companies as well— to come up with some unique passwords.

**22:31 Chris Romeo:** Yeah, and I guess another plug for something that Troy Hunt's responsible for. Troy has this haveibeenpwned.com site, and that's a place where he collects different data breaches and things that have occurred, different password hash dumps and stuff. So you can actually go and put your email address in to that site and see if your credentials have been breached or have been disclosed in any of the popular data breaches. And he trolls the kind of darknet and dark web and stuff for different dumps and different database dumps and things. And he gets people that send him a lot of different stuff from the underground. So, it's worth taking a look at and kind of understanding. But I like this idea of NIST saying, hey, you know, you should, You should have this type of a check. I just don't know how practical it is for the average company that's— unless somebody packages this up into a library and then into a service, I don't know that it's really going to be that easy to do for the average application development company.

**23:37 Robert Hurlbut:** True, and that's why Troy was trying to put that together to help some companies. But yeah, it's not a small undertaking. It's definitely some extra effort. And so, I think it's a good recommendation, but yeah, it's going to be interesting to see how it plays out for smaller companies and how they approach it.

**23:56 Chris Romeo:** Yeah. And maybe it's something that'll be more of a— they're just hoping we get there in 5 or 10 years because sometimes that's how these standards are written. They know it's not going to really be prevalent today, but maybe 10 years from now, if we had that capability, we'd be happy.

**24:14 Robert Hurlbut:** Yeah, certainly push us forward on this problem, I think.

**24:20 Chris Romeo:** Yeah, and then so if you continue through the NIST SP 800-63B, they get into 2-factor authentication, multi-factor authentication, a whole bunch of different things. And I guess my takeaway for the audience here is go read the document. We're just talking about passwords today, but it's definitely a good document to give a review if you're a security professional. You should understand what these requirements are that they're talking about in more depth. And there's actually some interesting stuff in there. And so I guess the last thing we wanted to plug here a little bit is it seems like all roads lead back to OWASP on the Application Security Podcast for some reason. But why is that? Why, Robert, why do all roads lead back to OWASP?

**25:02 Robert Hurlbut:** I think because there's so much information out there on application security. It's just a treasure trove of it.

**25:08 Chris Romeo:** Yeah. And so, uh, once again, they have what's called the, uh, Password Storage Cheat Sheet on OWASP.org. And what this is, it's a document that provides some of the same guidance that we just talked about from the NIST SP 800-63B. And that's just because they're both documents that have best practices described within them. But what they focus on in the Password Storage Cheat Sheet is what are the things that you need to do within your app, your authentication code, within the functionality that you're creating in your application to protect those passwords that you're going to store to the best possible way. And it's funny because they had like one of the first things in the cheat sheet is don't limit the character set and the max length for credentials. So they, I guess they agree with the NIST standard about not limiting the max lengths. They— and I guess they kind of still agree. They're just saying let people use whatever characters they want, and so they're not advocating that you have to have a complexity policy. So they're likely— those two are still in sync.

**26:19 Robert Hurlbut:** Yeah, that's good. One thing about setting a max length, I know that there was— Drupal had a vulnerability at one time where you could put in a long character length of 2,000 or something like that. But it turned out you could actually force a denial of service because of the amount of time it took for the system to process password hashes. You have to be careful and you have to test your system. If you set a very long password length, maximum length for passwords, you have to verify that your system can handle if you have 100 people that are doing that at the same time. Check it out, make sure.

**27:04 Chris Romeo:** Yeah, and then so another recommendation that the OWASP cheat sheet makes is use a cryptographically strong credential-specific salt. And so in, I guess, layman's terms, the way I understand this idea of a salt is when I store a password on the server side that nobody else is ever going to see, what I'm going to do when I create that hash is I'm actually going to create another kind of cryptographic filler piece of information, and then I'm gonna combine that together with the user's password, and I'm gonna hash the entirety of what the user submitted, the hash that came out of them, and then also some other type of cryptographic kind of nugget, I guess. And so what that means is that it's just, it's adding complexity on the storage side so that it's not just the user's password that was hashed one time and then here's the result. It was the user's password plus something else that just provides us with some more good security within the storage.

**28:11 Robert Hurlbut:** Right, because in that case, when you see a list of passwords in a database, all these password hashes rather, if you have a salt that's used to create that password hash, if you have 100 of those passwords that are exactly the same, they won't look the same with the password hash with the salt. So, that's one good reason for that, among others.

**28:33 Chris Romeo:** And I think the last takeaway I had from the password cheat sheet is a great way to kind of end this episode. And that is that they say, design password storage assuming eventual compromise, which is kind of a, I don't know, it's kind of like a, the sky is falling, the end of the world is coming type of approach. But if you build your password storage assuming that someone will eventually steal the hashes, you will— it'll just force you to architect it into a way that says, we're going to make this a punishment to anybody that tries to crack these hashes. We're going to make it as hard as we possibly can. We're going to salt the passwords that we're storing. We're going to use some— we're going to use the right algorithms, and we're going to use— we're not going to make this easy. It's not going to be MD5 we're using. It's not going to be SHA-1. It's going to be something that's that's even at a higher level to cause pain when somebody tries to crack these things. And so, I think it's a good way to design and approach an authentication system because it's going to cause you to have to make the hard decisions and say, we're going to go with the heavy-duty algorithms.

**29:43 Robert Hurlbut:** Right. And in that vein, thinking about even the operation of doing a hash or comparing a hash, if the algorithm you're using takes a few seconds, per password versus milliseconds per password, right there alone, if you have 100,000 passwords that you need— the attacker needs to go through and try to figure out all the hashes, a few milliseconds versus a few seconds makes all the difference in the world in terms of the amount of effort that the attacker is going to have to go through to try to find out all those passwords.

**30:20 Chris Romeo:** Yeah.

**30:20 Robert Hurlbut:** And so that's another thing to consider as well, is how long does it take for a typical hashing algorithm to process a single password hash that then, again, designing your system, thinking about compromise, how much time is it going to buy you? If you determine that you've been compromised, how much time is it going to buy you in order to inform your customers that there's been a breach?

**30:45 Chris Romeo:** Yep. And so I guess in conclusion here, we talked about the threats to passwords. I guess the action item for the listeners is go take a look at NIST Special Publication 800-63B. Go take a look at the OWASP Password Storage Cheat Sheet and figure out how you can incorporate the guidance in both of these documents into how you provide or perform authentication for your users. And we think— we thank you very much and have a great day.

**31:15 Robert Hurlbut:** Thank you.

**31:19 Chris Romeo:** Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Boring and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.org.

---

Source: https://appsecpodcast.com/chris-and-robert-passwords-identity-and-appsec/