Tag Archives: two factor authentication

Password Security Tips for Very Busy People

Password Security Tips for Very Busy People

If you needed another reminder that you shouldn’t use the same password on multiple online sites, yesterday’s news about the hacking of Mark Zuckerberg’s Twitter and Pinterest accounts is your teachable moment. Mr. Z. was apparently as guilty as the rest of us in password laxness.

From what we know, the hackers worked from a list of cracked accounts that came from a 2012 breach at Linkedin. While an initial round of over six million passwords has been available for some time, it’s now believed that the number of cracked passwords might be as high 167 million. Based on the  messages left by the hackers on his Twitter timeline, Mark’s password may have been on that new list.

Sure, “if it happens to the best of us, it happens to the rest of us”, is one take away. However, we can all do a better job in managing our passwords.

Am I Already a Victim?

Last week, I received an email from Linkedin saying my account was part of the new batch of cracked passwords. I changed my password, and I had already been pretty good (not perfect) about using several different passwords for the online accounts that I care about. But I now needed to revisit some of them as well.

1. Go to this site now and enter the email addresses that you most commonly use in setting up accounts. You’ll discover whether your password is known to hackers.

There’s a service that will tell if you have an account on a site that’s been hacked and the passwords doxed. It’s called have I been pwned?

Besides informing me that Linkedin was one of my breached accounts, the ‘have I been pwned?’ service also alerted me that another account of mine had been compromised.

Yikes! Fortunately, it’s one of my web accounts where I’ve frequently change the password. So no problem.

You may not be so lucky. If this service tells you’ve been pwned, you’ll have to immediately go to the affected web site, along with other accounts that share that password and change them.

But on hold on a sec before you do that.

Turn on Two-Factor Authentication

You shouldn’t waste a crisis. It’s now a good time to turn on two-factor authentication (TFA) if it’s provided.

Linkedin does offer this feature. It works with your cell phone by sending an SMS text with a PIN. Or if you don’t use SMS, the service will call you instead.

So the next time you logon to Linkedin, you’ll be asked for your password (the first factor) and for the PIN (the second factor), which is sent to your cell phone.

2 .Before reading any more of this post, go to your Linkedin profile and turn on TFA – you’ll find the setting under Privacy & Settings>Privacy>Security.

The next time there’s a data exposure, you won’t have to worry (as much) about your account being hacked. The hackers will fail the second factor test.

Besides Linkedin, Google, Twitter, Dropbox, Facebook, and Paypal have this feature as well. A lifehacker article from 2013 list additional web sites with TFA.

Google and others — notably Twitter, Linkedin, and Facebook — also offer their TFA as a service. This allows sites that haven’t implemented strong authentication to hook into, say, Google Authenticator, for instant TFA. Going forward, for those sites that support these TFA services, you can in theory have secure centralized authentication.

3. It’s a good time now to consider using the authenticator feature of Google, Twitter, or Linkedin for all your accounts. As a first step, I would turn on TFA for your Google and Twitter accounts as well. It will also make these services more secure. Do it now!

Correct Battery Horse Staple and its Variants

The best way to stop the whole chain of events that forces you to change passwords on multiple account is to  come with an uncrackable password in the first place.

The correct-horse-battery-staple method is one way to generate high-entropy passwords. You pick four random words out of the dictionary and use them as your password. This classic xkcd comic explains it nicely.


Source: xkcd

To remember the password, you devise a little story using the random words, thereby connecting the words together in your neurons. For example, “I showed the horse a battery with a staple on it, and the horse said correct”

Memory tricks where you connect stories to the actual words or ideas you want to recall are known as mnemonics.

I wrote about a variant of this technique where you make up a very simple one sentence story and use the first letter of each word as your password.

For example, here’s my one sentence story: “Bob the tiger ambled across the savannah at 12 o’clock last Tuesday”.

Unforgettable, right?

And the password that comes from this is: Bttaatsa12olT.

4. Now it’s your turn. Make up a memorable one sentence story that is long enough, at least 10 to 15 words, and try to use some punctuation and numbers. Take the first letters of those words and write it down once — just to see it. Throw away the paper. This is your new password. If you’ve been pwned—see #1—then use this as your new password. For anchor sites like Google or Twitter or Linkedin, change your password there as well, since these can in the future become your main authenticator.

Multiple Site Paranoia

More recently I’ve been using my own long one sentence mnemonic as my high-entropy password—I’m very confident it’s uncrackable.

Unfortunately, I didn’t use this technique with the Linkedin account I set up years ago, and hence I am one of the victims.

Can you use this same high-entropy password on multiple sites that are also guarded by TFA?

I’m not that paranoid so I would. But experts will tell you that even TFA has man-in-the-middle vulnerabilities and maybe somehow they launch a brute force dictionary attack against your encrypted password …

If you really want to avoid having to change multiple accounts if you’ve been hacked, then you may want to customize the one sentence story.

Here’s what I came up with. Balancing complexity with convenience, I now make a small part of my one sentence story variable —pick a subject, verb, or object to be the variable part.

And then use some letter in the website name please, not the first, but say the second letter — as the starting letter of another word to replace the subject, verb, or object.

If I want to reuse my “Bob the tiger” password, I could make the verb variable and use the second letter of the website name as the first letter of my new verb.

For Snapchat, my story might become: “Bob the tiger navigates across the savanna at 12 o’clock last Tuesday”.

For Twitter, it could read: “Bob the tiger walked across the savanna at 12 o’clock last Tuesday”.

You get the idea. You have a different password for each site.

For hackers who are used to quickly trying the cracked passwords on other sites besides the oringial, they’ll very likely go on to another victim when they fail to get in.

[Podcast] IoT Pen Tester Ken Munro, Transcript

[Podcast] IoT Pen Tester Ken Munro, Transcript

This article is part of the series "[Podcast] IoT Pen Tester Ken Munro". Check out the rest:

I had a load of fun chatting with Ken Munro of Pen Test Partners. The transcript I’m releasing below of the podcast is a good read, and well worth your time. One of the underlying themes that Ken makes is that security features are not a priority in consumer IoT devices.

If you’d like to read more about the details of how he broke into the iKettle wireless coffee maker, you can check out this post or watch this entertaining video. In short: using an antenna a hacker can unlink the coffee maker from its current network and then relink to his own special mobile access point. He’s then able to pull out the WiFi or PSK key of the home or business owner’s network from the coffee gadget!

Another attack that I allude to in the interview is based on the fact that some IoT devices Ken tests are actually access points when they’re in an unconfigured state. That was the case with the Ring wireless doorbell. So a hacker can take advantage of this by surfing into the device and then, yet again, grabbing the plaintext PSK of the owner’s network stored on the gadget.

One bit of advice Ken gives on dealing with IoT security weaknesses (and this should sound very familiar) is to change the defaults: always update the manufacturer’s settings for pins, admin passwords, and SSIDs (the wireless access point name) of the device!  Hackers count on these to be in their original state, thereby allowing them to more easily enter the gadget.


Inside Out Security: You’ve focused mostly on testing the IoT — coffee makers, doorbells, cameas –and it’s kind of stunning that there’s so much consumer stuff connected to the internet.  The Ring Doorbell and iKettle, were examples I think, where you obtained the WiFi PSKs (pre-shared keys).

Could you talk more your work with these gadgets?

Ken: Yeah, so where they’re interesting to us is that in the past to get hold of decent research equipment to investigate, it used to be very expensive. But now that the Internet of Things has emerged. We’re starting to see low-cost consumer goods with low-cost chip sets, with low-cost hardware, and low-cost software starting to emerge at a price point that the average Joe can go and buy and put into their house.

A large company, if they buy technologies, has probably got the resources to think about assessing their security … And put some basic security measures around.  But average Joe hasn’t.

So what we wanted to do was try and look to see how good the security of these devices was, and almost without exception, the devices we’ve been looking at have all had significant security flaws!

The other side of it as well, actually, it kind of worries me. Why would one need a wireless tea kettle?

IOS: Right. I was going to ask you that. I was afraid to. Why do you think people are buying these things? The advantage is that you can, I guess, get your coffee while you’re in the car and it’ll be there when you get home?

Ken: No. It doesn’t work like that …Yeah, that’s the crazy bit. In the case of the WiFi kettle, it only works over WiFi. So you’ve got to be in your house!


IOS: Okay. It’s even stranger.

Ken: Yeah, I don’t know about you but my kitchen isn’t very far away from the rest of my house. I’ll just walk there, thanks.


IOS: Yeah. It seems that they were just so lacking in some basic security measures … they left some really key information unencrypted. What was the assumption? That it would be just used in your house and that it would be just impossible to someone to hack into it?

Ken: You’re making a big step there, which is assuming that the manufacturer gave any thought to an attack from a hacker at all. I think that’s one of the biggest issues right now is there are a lot of manufacturers here and they’re rushing new product to market, which is great. I love the innovation.

I’m a geek. I like new tech. I like seeing the boundaries being pushed. But those companies that are rushing technologies to market with not really understanding the security risk. Otherwise, you’re completely exposing people’s homes, people’s online lives by getting it wrong.


IOS: Right. I guess I was a little surprised. You mentioned in your blog something called wigle.net?

Ken: Yeah, wigle is ….  awesome and that’s why WiFi’s such a dangerous place to go.


IOS: Right.

Ken: Well, there’s other challenges. It’s just the model of WiFi — which is great, don’t get me wrong — when you go home with your cell phone, your phone connects to your WiFi network automatically, right?

Now, the reason I can do that is by sending what are called client probe requests. And that’s your phone going, “Hey, WiFi router, are you there? Are you there? Are you there?”

Of course, when you’re out and about and your WiFi’s on, it doesn’t see your home WiFi router. But when you get home, it goes, “Are you there?” “Yeah, I’m here,” and it does the encryption and all your traffic’s nice and safe.

What wigle does — I think it stands for wireless integrated geographic location engine, which is crazy …  security researchers have been out with wireless sniffers, scanners, and mapped all the GPS coordinates of all the wireless devices they see.

And then they collate that onto wigle.net, which is a database of these which you can basically query a wireless network name … and work out where they are.

So it’s really easy. You can track people using the WiFi on their phones using wigle.net. You can find WiFi devices. A great example of that was how we find the iKettle, that you can search wigle.net for kettles. It’s crazy!


IOS: Yeah, I know. I was stunned. I had not seen this before. I suspect some of the manufacturers would be surprised if they saw this. We see the same thing in the enterprise space or IT. I’m just sort of surprised that’s just so many tools and hacking tools out there.

But in any case, I think you mentioned that some of these devices start up as an access point and that, in that case, you know the default access name of the iKettle or whatever the device is, and then you could spot it.

Is this the way the hackers work?

Ken: No, that’s right. The issue with an IoT WiFi device is that when you first put it up, you need to get through a process of connecting to it and connecting it to your home WiFi network.

And that is usually a two-stage process. Usually. It depends. Some devices don’t do this but most devices, say, the iKettle, will set itself up as an access point first or a client-to-client device, and then once you go in and configure it with your cell phone, it then switches into becoming a client on your WiFi network. And it’s going through that set of processes where we also found issues and that’s where you can have some real fun.


IOS: Right. I think you took the firmware of one of these devices and then was able to figure out, let’s say, like a default password.

Ken: Yeah. That’s another way. It’s a completely different attack. So that’s not what we’ll do in the iKettle. We didn’t need to go near the firmware.

But a real game changer with IoT devices is that the manufacturer is putting their hardware in the hands of their customers … Let’s say you’re a big online retailer. Usually you bring them in with application and you buy stuff.

With the Internet of Things, you’re actually putting your technology — your kit, your hardware, your firmware, your software — into the hands of your consumers.

If you know what you’re doing, there’s great things you can do to analyze the firmware. You can extract off from devices, and going through that process, you can see lots of useful data. It’s a real game changer, unlike a web application where you can protect it with a firewall … But the Internet of Things, you put your chips into the hands of your customers and they can do stuff with that potentially, if they have got security right.


IOS: Right. Did you talk about they should have encrypted the firmware or protected it in some way? Is that right?

Ken: Yeah. Again, that’s good practice. In security, we talk about having layers of defense, what we call defense in depth so that if any one layer of the security chain is broken, it doesn’t compromise the whole device.

And a great example for getting that right would be to make sure you protect the firmware. So you can digitally sign the code so that only valid code can be loaded onto your device. That’s a very common problem in design where manufacturers haven’t looked at code signing and therefore we can upload rogue code.

A good example of that was the Ring doorbell. Something that’s attached to the outside of your house. You can unscrew it. You can walk off with it. And we found one bug whereby you can easily extract the WiFi key from the doorbell!

Again, the manufacturer fixed that really quickly, which is great, exactly what we want to see, but our next step is looking at it and seeing if we can take the doorbell, upload a rogue code to it, and then put it back on your door.

So we’ve actually got a back door on your network.


IOS: Right, I know. Very scary. Looking through your blog posts and there were a lot of consumer devices, but then there was one that was in a, I think, more of a borderline area and it was ironically a camera. It could potentially be a security camera. Was that the one where you got the firmware?

Ken: Yeah, that was an interesting one. We’ve been looking at some consumer grade CCTV cameras, although we see these in businesses as well. And we’ve particularly been looking at the cameras themselves and also the digital video recorders, the DVRs where they record their content onto.

So many times we find someone has accidentally put a CCTV camera on the public Internet. You’ve got a spy cam into somebody’s organization! The DVR that records all the content, sometimes they put those on the Internet by mistake as well. Or you find the manufacturers built it so badly that ..  it goes on by itself, which is just crazy.


IOS: Yeah, there’s some stunning implications, just having an outsider look into your security camera. But you showed you were able to, from looking at the…it was either the firmware or once you got into the device, you could then get into network. Was that right?

Ken: Yeah, that’s quite ironic really, isn’t it? CCTV cams, you consider to be a security device. And what we found is not just the camera but also the DVR, if you put it on your network and ,,, it can create a backdoor onto your network as well. So you put on a security device that makes you less secure.


IOS: One of things you do in your assessments is wireless scanning and you use something, if I’m not mistaken, called Kismet?

Ken: Kismet’s a bit old now … There are lots of tools around but the Aircrack suites is probably where it’s at right now And that’s a really good suite for wireless scanning and wireless g cracking.


IOS: Right. So I was wondering if you could just describe how you do a risk assessment. What would be the procedure using that particular tool?

Ken: Sure. At its most basic, what you’d be looking to do, let’s say you’re looking at your home WiFi network. Basically, we need to make sure your WiFi is nice and safe. And security of a WiFi key  is how long and complex it is.

It’s very easy to grab an encrypted hash of your WiFi key by sitting outside with a WiFi antenna and a tool like Aircrack, which allows you to grab the key. What we then want to do is try and crack that offline. So once I’ve got your WiFi key, I’m on your network, and we find in a lot of cases that ISP WiFi routers, the default passwords just aren’t complicated enough.

And we looked at some of the ISPs in the U.K. and discovered that some of the preset keys, we could crack them on relatively straight-forward equipment in as little as a couple of days.


IOS: Okay. That is kind of mind-blowing because I was under the impression that those keys were encrypted in a way that would make it really difficult to crack.

Ken: Yeah, you hope so but, again, it comes down to the length and complexity of the key. If you WiFi network key is  only say — I don’t know — eight characters long and it’s not really going to stand up to a concerted attack for very long. So again, length and complexity is really important.


IOS: Yeah, actually we do see the same thing in the enterprise world and one of the first recommendations security pros make is the keys have to be longer and the passwords have to be longer than at least 8.

Ken: We’ve been looking at some … there’s also the character set as well. We often find … the WiFi router often might only have lower case characters and maybe some numbers, and those numbers and characters are always in the same place in the key. And if you know where they are and you know they’re always going to be lower case, you’ve reduced the complexity.


IOS: Right.

Ken: So I’d really like to be seeing 12-, 15-, 20-character passwords.

It’s not a difficult thing. Every time you get a new smartphone or a new tablet, you have to go and get it from the router then but really I think people can cope with longer passwords that they don’t use very often, don’t you think?


IOS: No, I absolutely agree. We sort of recommend, and we’ve written about this, that you can…as an easy way to remember longer passwords, you can make up a mnemonic where each letter becomes part of a story. I don’t know if you’ve heard of that technique.

You can get a 10-character password that’s easy to remember and therefore becomes a lot harder to decrypt. We’ve also written a little bit about some of the decrypting tool that are just easily available, and I think you mentioned one of them.

Was it John the Ripper?


Ken: John is a password brute force tool and that’s really useful. That’s great for certain types of passwords. There are other tools for doing different types of password hashes but John is great. Yeah, it’s been around for years.

IOS: It’s still free.

Ken: But there are lots of other different types of tools that crack different types of password.


IOS: Okay. Do you get the sense that, just going back to some of these vendors who are making these devices, I think you said that they just probably are not even thinking about it and perhaps just not even aware of what’s out there?

Ken: Yeah, let’s think about it. The majority of start-up entrepreneur organizations that are trying to bring a new IoT device to market, they’ve probably got some funding. And if they’re building something, it’s probably going to be going into production nine months ahead.

Imagine you’ve got some funding from some investors, and just as you’re about to start shipping, somebody finds a security bug in your product!

What do you do? Do you stop shipping and your company goes bust? Or do you carry on and trying to deal with the fallout?

I do sympathize with these organization, particularly if they had no one giving them any advice along the way to say, “Look, have you thought about security?” Because then they’re backed into a corner. They’ve got no choice but to ship or their business goes bankrupt, and they’ve got no ability to fix the problem.

And that’s probably what happened with the guys who made the WiFi kettle. Some clever guys had a good idea, got themselves into a position where they were committed, and then someone finds a bug and there’s no way of backing out of shipping.


IOS: Right, yeah. Absolutely all true.  Although we like to preach something called Privacy by Design — at least it’s getting a lot more press than it did a couple years ago — which is just the people at the C-level suite should just be aware that you have to start building some of these privacy and security ideas into the software.

Although it’s high-sounding language. And you’re right, when it comes to it, a lot of companies, especially start-ups, are really going to be forced to push these products out and then send out an update later, I guess is the idea. Or not. I don’t know.


Ken: That’s the chance, isn’t it?

So if you look at someone like Tesla, they’ve had some security bugs found last year and they have the ability to do over-the-Internet updates. So the cars can connect over WiFi and all their security bugs were fixed over the air in a two-week period!

I thought that was fantastic.

So they can update in the field … if you figured out that, brilliant. But they don’t have the ability to do updates once they’re in the field. So then you end up in a real stick because you’ve got products you can only fix by recalling, which is a huge cost and terrible PR. So hats off to Tesla for doing it right.

And the same goes for the Ring doorbell. The guys thought about it. They had a process whereby it got the updates really, really easy, it’s easy to fix, and they updated the bug that we found within about two weeks.

And that’s the way it should be. They completely thought about security. They knew they couldn’t be perfect from the beginning. “Let’s put a cable in place, a mechanism, so we can fix anything that gets found in the field.”


IOS: Yes. We’re sort of on the same page. Varonis just sees the world where there will always be a way for someone to get into especially newer products and you have to have secondary defenses. And you’ve talked about some good remediations with longer passwords, and another one we like is two-factor authentication.

Any thoughts on biometric authentication?

Ken: Yes. Given the majority of IoT devices have being controlled by a smartphone, I think it’s really key for organizations to think about how they’ve authenticated the customer to a smart device or, if they have a web app, the web interface as well, how they authenticate the customer to that.

I’m a big fan of two-factor authentication. People get their passwords stolen in breaches all the time. And because they will reuse their passwords across multiple different systems, passwords stolen from one place and you find another place gets compromised.

There was a great example, I think, some of the big data breaches … they got a password stolen in one breach and then someone got their account hacked. It wasn’t hacked. They just had reused the password!


IOS: Right.

Ken: So I’m a real fan of two-factor authentication to prevent that happening. Whether it’s a one-time SMS to your phone or a different way of doing it, I think two-factor authentication is fantastic for helping Average Joe deal with security more easily. No one’s going to have an issue with, “Look, you’ve sent me an SMS to my phone”.

That’s another layer of authentication. Great. Fantastic.” I’m not so much a fan of biometrics by themselves and the reason for that is my concern about revocation. Just in case the biometric data is actually breached, companies get breached all the time, we’ve not just lost passwords because passwords we throw them away, we get new ones, but if we lose your biometic, we’re in a bit more of a difficult position.

But I do biometrics work brilliantly when they’re combined with things like passwords. Biometric plus password is fantastic as a secure authentication.


IOS: Thanks for listening to the podcast. If you’re interested in following Ken on Twitter, his handle is TheKenMunroShow or you can follow his blog at PenTestPartners.com. Thanks again.

Windows 10’s Security Reboot, Part III: FIDO and Beyond

FIDO’s Universal Two Factor (U2F) is intended to make it easy for companies to add a strong second factor to their existing crypto infrastructure. Most of us are probably not ready to leap ahead to the password-less Universal Authentication Factor (UAF), which I touched on in the previous post in this series. So U2F is a comfortable half-way point that still leverages FIDO’s strong crypto technology but allows employees to continue with their more familiar password entry habits.

U2F is an ambitious initiative to raise the overall authentication bar for everyone. Rather than just another proprietary approach, U2F is instead an open-standard with its own ecosystem supported by browser vendors and device makers.

It has a major advantage over current schemes in that it addresses a serious flaw with current implementations of two-factor authentication (TFA).

What’s the issue with vanilla TFA?

It’s actually vulnerable to straightforward man-in-the middle attacks. Typically an attack would be initiated through a phish mail.

Phishing for Factors

Let’s quickly review TFA. In addition to asking for the password–what the user knows–it also requires something they have: say, a cell phone. For example, when logging into a TFA-based web site, the user is asked to enter an additional one-time password (OTP) that’s then sent as an SMS. The OTP is often a short numeric string with a limited lifetime.

A clever hacker simply has to set up a fake web site that looks like the target—for argument’s sake, an overnight delivery service. A phish mail could be sent to employees in a large company asking them to, say, verify a delivered package by clicking on a link to the phantom site.

In standard man-in-the-middle fashion, the hackers now simply forward the password to the real site, triggering the OTP. When the user enters the OTP, it too is forwarded to the real site, giving complete access to the hacker.

Mission accomplished.

U2F Makes it Hard

U2F does it differently. It takes full advantage of the public key crypto that I talked about last time. Like UAF, it uses the public-private key pairs, which are initially registered for the device on which the second factor is based.

Bottom line: U2F provides a convenient way for companies to boost identity verification without having to add fancy biometric techniques.

Vendors have already introduced FIDO compliant dongles—essentially a USB drive on which has the private key is stored. Just around the corner, smart phone vendors will soon be able to support the FIDO standard through Near Field Communications (NFC) technologies.

Here’s how it all works.fido auth u2f

When users log on to a U2F-supported website or corporate portal, in addition to entering their password they’ll be asked to insert their FIDO dongle into their laptop or device. When smart phones start supporting FIDO, users will place or swipe their iPhone and Androids near the laptop’s NFC reader.

Anyway, the dongle is then asked to sign a random string that’s concatenated—and this is crucial—with the URL of the web site asking for the information (see the diagram).

When this signed credential is sent back to the website, it is decrypted. If the random string matches, then the user has proven himself. And if the decrypted URL matches what the user was expecting—i.e., the address of the website verifying the second factor—then the website is authenticated as well.

Not Perfect, But …

Sure, U2F requires support from Chrome, Firefox, and other vendors to pass URLs to the dongle. And no, it’s not a foolproof solution, but you can see how it eliminates man-in-the-middle attacks.

If a fake site passes the credential to the authenticating server of the real site, it would be rejected! The fake site’s phishy URL (www.fed3x.com), when decrypted, couldn’t possibly match the URL of the real site (www.fedex.com).

This is a very good solution!

While there are some potential weak points, U2F should close the door to low-skilled hacks and could eliminate many, many breaches.

No doubt hackers are working on malware that can get around U2F’s strong security—possibly some clever keylogger that embeds itself on the user’s device. It also wouldn’t surprise me if some presentations at this year’s Black Hat conference start suggesting possible hacks. We’ll see.

Nothing in Windows 10 Is Nailed Down

While I was hoping to end this post with a discussion of another intriguing Windows 10 security improvement, a more serious effort at addressing data loss prevention (DLP), I’ll have to punt. There’s even less information available on this than on the authentication improvements I’ve been discussing.

Of course, none of us know how any of this will be implemented because Windows 10 is about a year away from a general release and features are, as Microsoft has noted, “subject to change.”

While I am cautiously optimistic that some of the worst abuses of Windows authentication hacking will soon end, the realist in me says new hacks are in the works.

Windows 10’s Security Reboot, Part I: Authentication

Windows 10’s Security Reboot, Part I: Authentication

There’s incredible excitement about the Windows 10 release. If you completely quantum leap over Windows 9, you’d expect big things. In December, I was talking with NYU-Poly’s Professor Justin Cappos. He’s a security expert and had nothing but high praise for Microsoft’s security group. But he added their cutting-edge research doesn’t necessarily make it into their products.

With Windows 10 officially launched in January, it looks like the security researchers have finally gotten their way.

The End of Pass the Ticket and Pass the Hash?

While Cortana and HoloLens may have stolen the show at the launch event, the other exciting news–at least for us security geeks –is that Microsoft is planning a complete revamp of its rusting security infrastructure.

Jim Alkove, the Windows 10 product manager, gave us all a heads-up about what to expect in a post  he published back in October. That was also about the time that Microsoft released the Windows 10 Technical Preview, which you’re free to download and try out on a spare PC or in a virtual machine (VM).

In my next few posts, I’ll take up some of the major changes in authentication and data security that are currently slated. The caveat is that none of this is completely finalized. The official release of Windows 10 is year away.

In any case, Alkove says that Windows 10 “aims to eliminate” — long pause — Pass the Hash and Pass the Ticket.

Loyal Metadata Era readers know that we’ve dived somewhat deep into the PtH and PtT waters.  And we’ve also written an ebook covering these two hash stealing approaches as well as other attacks used against Microsoft’s NTLM authentication protocol.

For those just tuning in, the key point is that both Windows and Linux never store plain-text passwords. That’s just Security 101. Instead they perform a one-way encryption of the password, known as a hash, and keep that instead. By all means, read Rob’s hashing post.

Unfortunately, in Windows, the password hash is equivalent to the password in terms of the power it gives you—the fancy crypto-speak for this is plain-text equivalent. In other words, hackers who are able to get inside a Windows system—and that’s easily accomplished through phishing—just need to collect password hashes to masquerade as other users.

Where do they find these hashes? Windows keeps them around in the Local Security Authority Subsystem Service (LSASS). Essentially, they’re stored in memory on a user’s laptop or desktop device.

Containers Are the Answer

Having these powerful password hashes on users’ machines instead of storing them in a safe central location is a feature (not a bug) of Single Sign On (SS0). With SSO enabled in most organizations, Windows can reuse the password hash in LSASS—remember, it’s equivalent to the password—without inconveniencing the user.

Hackers have been very effective at exploiting this feature of SSO. Using malware such as mimikatz, they’re able to easily scoop up the hashes from memory, effectively stealing user credentials without having to know the password itself.

With Window 10, though, Microsoft hopes to stomp out these tools by placing the hashes in a walled off part of memory–technically they’ll put the LSASS in its own VM.

Microsoft, of course, has developed a VM technology, known as Hyper V, and in this latest Windows version, it looks like they plan to take more advantage of it.

It’s way too early to say whether this approach will succeed in blocking Pass the Hash and Pass the Ticket—the devil is always in the implementation details.

We’ll continue with our overview of Windows 10 security in our next post, where we will take up other authentication changes. This includes multi-factor authentication, tighter integration with enterprise PKI, and we’ll learn about FIDO and security ecosystems.

The Lowdown on PCI DSS and Two-Factor Authentication

The Lowdown on PCI DSS and Two-Factor Authentication

With the big security breaches from last year on our minds and with little new information available, there’s still plenty to puzzle over. One aspect of the Target breach that left security observers scratching their heads was the ease with which the hackers were able to gain access to the internal network by just swiping a password. Target was PCI compliant, but isn’t there something in their standards about two-factor authentication (TFA)?

That would be the 8.3 requirement in the PCI Data Security Standard (DSS), which reads “Implement two-factor authentication for remote access to the network by employees, administrators, and third parties.” This is the language of the 2.0 version, which was in effect at the time of last year’s breaches.

What gives?  I decided to make some calls to a few  PCI experts I know.  They all verified that TFA was most definitely in effect in 2.0 and it has only been slightly tweaked in the new 3.0 version.

I also began to understand that in real-world PCI, non-tech savvy retailers need guidance on deciding what’s important and what’s not in a standard with over 200 separate requirements.

It’s helpful to think of DSS as what the teacher expects you to ideally know, but the actual test of knowledge may be somewhat less comprehensive. PCI audits are conducted by Qualified Security Assessors (QSAs), who are  independent companies that certify compliance based on the explicit testing procedures also found in the standard.

To meet the two-factor authentication requirement, the QSA merely has to (in DSS 2.0) “… observe an employee (for example, an administrator) connecting remotely to the network and verify that two of the three authentication methods are used.”

You read that right—one employee. With this type of feedback from the teacher, it’s not surprising that merchants were confused by this particular requirement. So at the time of the breach, Target would have very likely still have passed the exam, based on the testing procedure.

Thankfully, the test has been tightened in 3.0. The QSA now has to “examine system configurations for remote access servers”.  And that would presumably include looking at, say, Group Policies in effect for Active Directory to see that authentication is turned on. Also the testing procedure has been expanded to require observing  a “sample of personnel connecting remotely to the network”. This is far more accurate way to evaluate the students.

While tests are important, of course, it seems that these retail breaches may say more about the security mindsets of companies. In other words, you need to make security ideals, especially the 4 As (authentication, authorization, auditing, and alerting), a part of “business as usual” and not something you do just to pass an exam. Suffering the pain of a data breach is far worse than any non-compliance penalty—just ask the Target CEO.

Image credit: BArchBot