VARONIS EBOOKThe Essential Guide to Understanding Password-based Authentication

2The Essential Guide to Understanding Password-based Authentication

THE ESSENTIAL GUIDE TO UNDERSTANDING PASSWORD-BASED AUTHENTICATIONAnd what it means for your company’s data security OVERVIEW

The news these days is filled with hackers getting into corporate IT

systems. How are they accomplishing their data heists? Verizon’s

Data Breach Investigations Report (DBIR), a key resource of hacking

stats for security researchers, notes that most hacking incidents

involve relatively low skills in breaking down doors . Many times the

technique is quite simple — they guess the password of a user’s

account!

Security pros have known for many years that passwords alone are an insufficient means for authenticating or validating that a user is who he or she claims to be. New authentication techniques have moved beyond just using a user name and password as a credential — multi-factor authentication has become table stakes for many security-smart businesses.

In the pre-Internet era the password as a credential worked pretty well. Users would go to the office and login to an ASCII terminal directly connected to a computer. In those days, you were given the password by the system administrator — someone you would actually meet in-person when you were first hired.

That was then. With the Internet and remote logins, physical location is less controllable, and passwords are not as reliable a credential. Employees are no longer restricted to a well-secured central office and can login in from anywhere — the “no one knows you’re a dog” problem.

To help non-technical managers, executives, and IT managers without strong security backgrounds understand how authentication works in the real world, we’ve put together the following Q&A.

3The Essential Guide to Understanding Password-based Authentication

I just login to my favorite sites using my password. So besides checking my password, is there additional authentication happening under hood?

Yes, absolutely. In recent years, even casual users of web sites

— especially banking or medial — have probably noticed new

authentication steps.

Please confirm your identity

To confirm that this is your computer, please answer the following security question.

What is your pet’s name?

Answer:

Confirm

For example, if you’ve attempted to log in from a different computer than the one you usually use, you may have noticed that you’re prompted for additional information, or that your attempt is rejected. The underlying authentication software considers accessing an account from a new computer or different IP address a possible sign of hackers. Typically, the software will ask those “secret questions” that you entered when you set up your profile. It’s essentially a way to further prove you are who you claim to be.

Recent innovations go beyond simple passwords. You may have heard some of these terms: hashing, tokens, challenge — response, digital certificates, Kerberos, OAuth, etc.

4The Essential Guide to Understanding Password-based Authentication

No I haven’t! I think I have the big picture though — passwords are not enough anymore. Can you give me a broad overview of how password authentication has evolved?

A password is like a set of house keys that can be duplicated or

stolen. There were some early attempts to make it more difficult for

hackers to forge them. In the digital world, of course, password theft

is (usually) not done physically. Unless a hacker is directly looking

over your shoulder when you login, it’s more likely that intruders find

the password either by spotting it in a file or database or else by

capturing it in-transit on a network.

So one of the earliest innovations was to avoid storing the password in an easily readable format, or plaintext. (Beware: some sites still commit this cardinal sin — see http://plaintextoffenders.com.)

5The Essential Guide to Understanding Password-based Authentication

Wait, but if the system never stores the password, how does it validate the identity of the user entering the password?

Early computer science researchers — circa 1970s and 1980s —

came up with the idea of trapdoor, or one-way functions. Using some

mathematical operations, known informally as hashing, they took

a password and generated another number or string. The hashed

string no longer resembles the original plaintext — you can think of

it as encrypted. And it’s this disguised password string that’s stored

instead!

For argument’s sake, let’s say my secret password is Rud0lfo and the trapdoor function as part of an authentication module generates a hash of “100&*50” and then stores the weird looking hash string sequence in an OS file for later reference.

Obviously, it’s of no use to the hackers. But now the authentication works by taking whatever password is entered by the user, hashing it, and then comparing the results against the hashed password in the file. If they match, the user is authenticated.

100&*50100&*50Rud0lfo

Matches hash fileUser

authenticatedUser enters password

100&*50

Password-free authentication by comparing hashes.

So the interesting thing about these one-way functions is that they’re not easily invertible. In other words, even if you were told the formula or algorithm, you wouldn’t be able to come up with a way to get the original input. Cyber thieves who scooped up the hashed passwords wouldn’t be able to work backwards to obtain the original string.

At Varonis’s Metadata Era blog, you can read more about these one-way hash functions. Caveat: there are attacks, unfortunately, that under certain conditions can determine the underlying password from the hashed text but we’ll get to this later.

6The Essential Guide to Understanding Password-based Authentication

Can you make this point about “one-way-ness” a little clearer?

Think of a hashing like grandma’s meatballs — you can’t take one

of her meatballs and deconstruct it back into the exact quantities of

meat, cheese, water, oil, and breadcrumbs grandma used because

that information was destroyed during the cooking process.

What’s more, it’s theoretically possible that multiple variations of

grandma’s recipe could produce identical meatballs. So, given any

one meatball, you wouldn’t be able to tell which recipe variation

produced it.

SECRET PASSWORD:

100&*50

Rud0lfo

Hashing passwords is very much like grinding meat for meatballs.

Or if you don’t like the meatball metaphor, there’s also a phone book example that some find useful. In this scenario, consider an incredibly enormous hypothetical phonebook with, say, trillions of entries. A one-way function would work as follows: for each letter from the password, a phone book entry is found whose last name starts with that letter, and then the associated phone number is used as the value of the hash.

A hacker without a computer wouldn’t be able, for practical purposes, to decode the hash value, so one-wayness is preserved. However, this does bring up a larger point about brute-force attacks with computers that we can discuss later.

7The Essential Guide to Understanding Password-based Authentication

Great. Problem solved, case closed.

Not quite. Along came the technology disruptions of the 1990s:

personal computers, local area networks, distributed computing, and

of course the Internet.

The scheme above works well in a trusted computing environment with terminals directly connected to a main computer. But in a distributed environment, users instead send the hashed password over the wire to login or request other services from a remote server, making it possible for an eavesdropper to intercept. Remember: in a network, apps are communicating by messaged-based protocols and the hash is just a field in a message.

So we’re back to square one! Why? You can think of the hash of the password as giving you the same power as the password — this is known as plaintext equivalent in crypto-speak. Suppose hackers gain access to the network and scoop up packets until they discover a hashed password. They then craft a new logon packet with the pilfered hash value, sending it back to the remote service. This is more than a theoretical possibility, and it’s known as a replay attack.

Yes, there are ways to avoid a replay attack. The simplest solution is to append a time of day value or some unique counter value to the password and then do the hash. But early authentication solutions, which I’ll get to later, didn’t take this extra step. Likely because they thought the hackers were not that clever!

Roger proveshe is “Roger”

by sending a password

Ed pretends to be Roger

Damien requestsRoger send

proof of identification

Meanwhile, Ed is eavesdropping and keeps the password

DAMIENROGER

ED

********PASSWORD

Damien requestsRoger send

proof of identification

DAMIEN

ED

********PASSWORD

********ROGER’S PASSWORD

LATER...

Dangers of sending passwords or password equivalents over the network.

We need a different approach that doesn’t send the hash of the password over the wire. The fancy term for this is zero-knowledge transfer.

8The Essential Guide to Understanding Password-based Authentication

How can you login if you can’t send any information about the password?

That’s where challenge-response protocols come into play. Security

researchers developed a technique to prove that a user (or client

app) has knowledge of the password hash without sending it over

the network. And yes, this is an example of zero-knowledge transfer

that just I talked about.

That kind of makes sense, but how do you prove knowledge of the password hash without tipping your hand, so to speak?

The researchers came up with the powerful idea of using the hash of

the password in an indirect way: as a key in a symmetric encryption

algorithm, say DES. You’ve heard of DES?

I know about DES. It’s kind of a standard encryption algorithm used on the Internet. The same key for encrypting contents can also be used to decrypt it — that’s why it’s called symmetric.

SYMMETRICAL DATA ENCRYPTION STANDARD

CLIENT SERVER

ENCRYPT DECRYPT377$$#*@11111swordfish swordfish

DES uses the same key to both encrypt and decrypt.

That’s right! As long as both parties have the same password, they can set up an encrypted conversation. Here’s how challenge-response works. A client logging into the system, would receive a challenge: given a random string, please DES encrypt it with your secret key, the password hash. The encrypted string would be sent back to the server, which, of course, also has the password hash of the user. The server decrypts the challenge string and if the results matches the challenge that what was sent, the user would be authenticated.

The interaction never involves sending any information about the password over the wire!

9The Essential Guide to Understanding Password-based Authentication

The client and server both prove they have knowledge of the secret by encrypting and decrypting the challenge using their own copies of the hash value.

Great idea. Has anyone commercialized this?

Sure. You’ve heard of a company called Microsoft? They also had to

grapple with the problem posed by the new technologies. Early on,

say by the mid- 1990s, they developed an authentication system for

their NT environment, known as NTLM. They were also aware of the

problems of storing or sending a password hash over the wire. So

their NTLM used a challenge-response protocol very much like what

I described above. And it was pretty effective until …

Ok, what’s the catch?

The devil is always in the details of these authentication protocols.

The first vulnerable point was that the challenge was not always random! You can see the hacking possibilities: if someone was able to snoop on the wire, they could record challenges and responses.

They would then stealthily send login requests — earlier NTLM didn’t have a request limit — until they got a repeated challenge and the hacker would resend the saved response from a prior. It’s an example of the replay attack — I mentioned earlier: you resend the answer to a challenge that’s already known.

In fact, an even earlier version of NTLM, sent the same challenge each time, making it completely breakable by snoopers.

After Microsoft fixed these early problems in challenge generation, a more direct attack on NTLM was discovered. Because of technical flaw in the algorithms, it was possible to launch dictionary-style attacks by setting up a man-in-the-middle server.

10The Essential Guide to Understanding Password-based Authentication

Ok, I’ve encrypted “swordfish” with the password hash and I have weird 24-byte string.

Server compares with itsencryption of swordfish,which matches.

You are worthy,please enter!

User Server

password

*********

User types password intologin dialog box

Hi. I know you’re claiming to be user XYZ, but you’ll need to prove it.

377$$#*@11111

377$$#*@11111

I’m sending you a challenge string, “swordfish” which I want you to DES encrypt using the hash of your password as a key.

Challenge-response works by a server asking the client to encrypt a random challenge string using a password hash.

Dictionary? Man-in-the-Middle?

Let me explain in a little more detail because the ideas here are

useful for a more general understanding of how hackers exploit

security holes.

To quickly review: In an early version of NTLM protocol, Microsoft relied on challenge-response protocol wherein the client was asked to encrypt a challenge string sent by the server. For the encryption, Microsoft used the hash of the password as the key to DES. If the client encrypted the challenge successfully — that is, it matched the server’s own encryption based on its copy of the password hash — then the server allowed entry.

Unfortunately, Microsoft divided the password hash into three smaller strings to use as, what else, but three smaller DES keys.

11The Essential Guide to Understanding Password-based Authentication

I think I’m following this.

Well, a lot of folks who looked into this found the approach

confusing, and ultimately very vulnerable. Microsoft took each of

the smaller DES keys and used them to separately encrypt different

parts of the challenge. Or to say it another way, the response was

the concatenation of the same challenge encrypted with three

smaller keys.

As any cryptographer will tell you, when the key size is too small, the encrypted data becomes vulnerable to what’s known as a brute-force attacks. That means you simply try every key possibility until you crack the code. As it turns out, because of the smaller DES key in early NTLM — 7 character sequences of the hash or in computer-speak, 56 bits — a try-every-combination approach is possible. And in fact there’s now special purpose hardware that can crack DES encryptions when the key is 56-bits or smaller. A hacker snooping on a network would feed this DES machine the server challenge and the client’s encrypted response. The DES crackware would return—after a day or two of computing – with the key, in this case, the password hash used by NTLM.

EXAMPLE:

d0G5Fr0gvs.

A DES key of length 3 requires at most

16,777,216 permutations to crack the encryption.

A key of length 7 requires about

7*1016 combinations to crack the encryption.

But hacker’s don’t really need special hardware! By being a little clever about selecting passwords, they build pre-computed tables or dictionaries based on an even smaller set of possibilities. For example, many passwords that users generate on their own — without guidance from IT! — are short and typically contain parts of words or names. With this in mind, hackers can work with a smaller number of likelier plaintext passwords in creating password hashes — these are keys that ultimately encrypt the challenge.

It turns out that the pre-computed tables in practice don’t have to be very large to be effective — something like several terabytes of data could be generated and stored by hackers with even modest budgets.

12The Essential Guide to Understanding Password-based Authentication

So NTLM uses smaller keys to encrypt the password, and that let hackers simply generate all the possible hashes. And the password hashes are then used to encrypt the challenge using DES.

But what do you use for the challenge itself, the random string that is sent by the authentication service?

Great point! Pick any challenge because this technique involves

a man-in-the-middle scenario. You’ll understand this in a second.

Hackers set up a rogue server, and are clever about directing users

to connect to it. There is more information here on how this can be

done - you’re effectively fooling the user into making a legitimate

request to a fake server.

DES

passw

ord:

Peter hash: %$2**121

Evil NTLM Server:takes over from the real server and sends known challenge (aardvark) to user

User takes the challenge text (aardvark) and encrypts it with his simple password (peter), using the hash of the password as key to the DES encryption

User Evil Server

Real Server

Evil Server then looks up encrypted challenge in a specially prepared dictionary.

The dictionary has encryptions of known challenge (aardvark) using common passwords as a key.

Dictionary

Peter, %$2**121Robert, !@#$(@Annie, !#$#

The whole NLTM man-in-the-middle attack in one picture: fake server sends known challenge to client, and then decodes response by searching a pre-

computed dictionary.

13The Essential Guide to Understanding Password-based Authentication

I think I see how this plays out!

Yup, the hacker sets up the fake server, and when a client connects

to it, the server sends out a known challenge. But that’s the same

as what was used in their “devils’ dictionary table. Think of this

dictionary as containing line after line of plaintext passwords, the

hashed versions, and then finally a known challenge encrypted with

the associated password hash.

And when the client sends back a response, it’s looked up in the table. If there’s a match, the hacker now knows the hash of the password (and the password itself of course), and therefore has enough information to take over that user’s identity.

And I hope you’re now seeing the more fundamental problem — the

hash of the password is as revealing as the password! Internally, it

gives you the same power as the password.

There’s another attack, known as Pass the Hash or PtH, which takes advantage of this.

14The Essential Guide to Understanding Password-based Authentication

Before we get to Pass the Hash, did Microsoft ever fix this problem?

Yes! They improved NTLM to make it impossible for the hackers to

use this faker server model. By the way, the authentication algorithm

I talked about is known as NTLM v1, which was vulnerable to, as I

mentioned, replay and dictionary attacks.

Anyway, in the upgraded NLTM v2, Microsoft hit on the idea of adding a time stamp to the challenge, essentially making the challenge unique, thereby preventing replay attacks. They also forced the server to authenticate itself — just as the client was authenticated by encrypting the server challenge. In other words, the server had to prove its credentials to the client. This was very effective in blocking the man-in-the-middle scenario I sketched out above.

Bottom line: you should be on NTLM v2!

Even so, with NTLM v2, there are still some problems. You can read more about NTLM here — this points to an excellent resource for IT folks interested in the nitty-bitty details of the protocol.

By the way, has anyone ever come up with a more secure authentication protocol that avoids the major pitfalls we were just talking about - man-in-the middle and brute-force?

The answer is yes. MIT researchers in the 1980s developed open-

source Kerberos authentication software. The protocol is more

complex than NTLM and was meant for distributed computers on

an untrustworthy network. Kind of what we have today. How good

is Kerberos? Even Microsoft recognizes it as superior to NTLM and

openly recommends and supports it — albeit through their own

version.

Unlike NTLM, there is now a separate entity that issues a credential — in Kerberos language it’s called a Ticket Granting Ticket or TGT. This separate entity has a name as well: Key Distribution Center or KDC. Going back to our physical world metaphors, the KDC is like the Department of Motor Vehicle issuing licenses or, say, the State Department with it passports — both real-world credentials that are hard to forge.

It’s important to point out a few things. The TGT does not on its own allow a client to access OS and system services — file system, email, CRM, etc. — instead it’s used indirectly to get another ticket or token that would then be presented to a service.

15The Essential Guide to Understanding Password-based Authentication

The TGT can’t be re-played or crypto-analyzed to derive a password hash. It’s encrypted using a very secure algorithm — not DES by the way — with a separate private key that only the KDC knows about. If a hacker got the TGT, it would be useless.

This gets complicated, but the TGT is paired with another key called a session id, which is itself encrypted with, you got it, the hash of the user password. To even gain access to a specific service, a user or client app would first present the TGT along with the session id to something called a Ticket Granting Server or TGS. And then finally, after receiving another ticket from the TGS, it would present this second ticket to gain entry to a service!

You can learn more about how Kerberos implements its authentication model at our Metadata Era blog.

Authentication ServerAuthenticates to

Ticket to Get Ticket

Ticket to Get Ticket

Ticket

Ticket

Ticket GrantingServer

Service Server

2. Client gets a time-stamped ticket from Authentication Server

3. Client contacts Ticketing Granting Server. Ticket verifies identity and asks for a service

1. Client authenticates to Authentication Server

4. If the Client is eligible for service,Ticket Granting Server sends ticket to Client

5. Client contacts Service Server. Ticket proves it has been approvedto receive the service. Communication is then initiated

CL

IE

NT

Kerberos is very complicated, but very secure.

16The Essential Guide to Understanding Password-based Authentication

Stop my head is exploding.

Ok, it is complicated, but it’s also very secure. By the way, Microsoft

made Kerberos the default authentication protocol starting at around

Windows 2000.

However, this leads to our next topic. While Microsoft recommends Kerberos, many IT groups can’t completely cut their ties to NTLM — mostly because lots of client apps (email, browsers, VPN, file sharing) still depend on it. And then there’s SAMBA, a suite that provides Windows file and print services for UNIX/Linux, which also uses NTLM.

Ok, so you enable NTLM v2, eliminating replay attacks and making man-in-the-middle very difficult.

But you’re still not secure. There’s a newer form of attack that takes advantage of NTLM’s direct reliance on the hash of the password.

Pass the Hash?

Yes. To get back to a point I made earlier, the hash of the password is

not something you want to expose — that was the reason behind the

challenge-response protocol! But if a hacker could gain access to

the hashes in an NTLM system, then it would be possible to respond

to the challenge — the hacker would use the hash of the password

to encrypt the challenge, and then be authenticated. Game over.

So a PtH attack requires a hacker to first get a foothold on a user’s desktop. Hackers have always been good at this, and with phishing attacks, they have a new “vector” to gain entry. Once in, they go about trying to find these password hashes, which unfortunately can all too often be accessed on users’ computers!

17The Essential Guide to Understanding Password-based Authentication

NTLM was designed to avoid exposing the hashes over the wire, but now you’re telling me they can find them on employee computers. Why didn’t Microsoft lock this data down in a single location?

Great question!

There’s something known as SSO or Single Sign On. It’s a technique that lets users login once without forcing them to re-login when networking to other computers or accessing new services. Windows implements SSO by caching the password hash on a user’s computer — i.e., keeping it in memory.

Let’s say I’ve entered my password, NTLM v2 has authenticated me, and I’m now logged in. Suppose I now need to access a file on the network drive. I would therefore have to go through another authentication with the Windows file service. Most users don’t want to re-enter their passwords — it’s inconvenient.

SSO simply takes the password hash stored in memory and then feeds it to the NTLM authentication algorithm. This process avoids having to ask the user again to enter a password every time a new service is requested. Think of SSO as a convenience, but with dangerous side effects.

By the way, Windows is not alone in implementing SSO — there’s a similar feature in Linux OSes.

username: Wah Yaronpassword: a1b2c3

Wah enters username and password

Wah’s user session and proves Wah’s hash to Server

User: WahPassword Hash: !#$%$Q

User: WahPassword Hash: !#$%$Q

Server creates session for Wah

Wah should have access

With Single Sign on, hackers don’t have to crack codes, they simply grab password hashes from memory.

18The Essential Guide to Understanding Password-based Authentication

How exactly do hackers retrieve the cached hashes?

It’s easy enough. There’s hacker-ware and penetration testing

software that can find the hashes in memory. The only catch is that

the hacker needs to have local admin access. But this is often not

much of an obstacle. Many times, IT forgets to change defaults or

leaves easily guessable passwords for the admin accounts.

Essentially, hackers go on a hash collecting spree, by hopping from one computer to another. They’re looking for hashes of users with elevated permissions. For example, if a domain-level admin has been logging into ordinary users’ computers – say to fix a problem — then this hopping strategy makes it more likely the hackers will find these more valuable hashes in memory.

Bottom line: Security researchers know that PtH is a standard part of hackers modus operandi. Once they get in — using, say, phishing or SQL injection — they almost invariable try PtH.

PtH seems to bring everything back to square one! Hackers getting the password hash is just as bad as hackers getting the password.

I agree PtH is not good news.

19The Essential Guide to Understanding Password-based Authentication

But Kerberos, which you mentioned earlier, doesn’t have this PtH problem, right?

I wish I could answer yes, but unfortunately Kerberos has an

equivalent security hole known as Pass-the-Ticket or PtT. You can

read more about it in a Metadata Era post.

Briefly: in implementing SSO in a Kerberos-based Windows system, the TGT and session ID are kept in memory, and in fact the same part of memory that the NTLM hashes are stored — Local Security Authority Subsystem or LSASS. If hackers got these two items, then they would be able to gain access to the TGS, at least for a short period of time. The TGT comes up with built-in expiration data, so a PtT attack would have to work in a shorter time frame.

By the way, we’ve been talking about authentication in an enterprise environment. Have there been innovations in the web when accessing sites and using web services?

Yes, and it’s called OAuth. When a website, say, wants to use the

services of another — such as Bitly posting to your Twitter stream —

instead of asking you to share your password — which of course you

never want to do — it uses OAuth instead.

OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away the keys to the kingdom. OAuth shares similar ideas with Kerberos in terms of using tickets and other credentials. You can read more about OAuth and find useful resources in another Metadata Era post.

20The Essential Guide to Understanding Password-based Authentication

You’ve given me a lot of information. But I need a practical take-away. For those in Windows environments, say with NTLM, is there anything they can do to lessen the chances of credential hacking?That’s right, you’re in a boat with lots of others. Here’s some very practical tips to mitigate the risks of PtH and PtT attacks:

• Don’t create local admin accounts on Windows machines! Thankfully, newer Windows OSes — Windows 7 and 8 — by default don’t add local admin account.

• Even better, Microsoft added a new malware defense known as User Account Controls or UAC, which requires explicit authorization for a user (or software app) to gain elevated privileges. Admins know UAC through the Consent or Credential prompts that pop up when they do legitimate work. While they may find this somewhat inconvenient, it does go a long way towards preventing hackers from getting a critical foothold.

• For organizations with older OSes, IT should enforce a policy of creating unique and robust admin passwords for each user’s machine. It’s a low-effort remedy for preventing hackers from easily guessing admin credentials and then reusing hashes on other machines. One simple trick is to append the machine name (or variation of it) to the password.

• Another powerful mitigation that works on both old and new Windows OSes is to prevent ordinary and local admin users from directly networking into other users’ machines and harvest more hashes. In an Active Directory environment, you’d do that by using the Group Policy Object (GPO) Editor to disable Remote Desktop Connections. You can read more about how to do this here.

• Finally, it makes sense to limit the high-value password hashes from spreading in the first place. While the above mitigations restrict and control access to admin accounts, which the hackers need to launch PtH, it may ultimately be a losing battle! Hackers are always finding new ways to get admin access. The rule is simple: only give domain administrators the right to access machines with equally high-privilege levels — i.e., domain controllers — and never allow these same accounts access to plain-old employee laptops and desktops. We never want a hacker to find the hash of a DA cached in memory — it gives them the keys to the kingdom!

21The Essential Guide to Understanding Password-based Authentication

This helps! Do you have even more basic advice to gain quicker IT buy in?

Try two-factor authentication or TFA. In addition to requiring users to

enter a password — something they know — you now force users to

access something they have — say a cell phone or a PIN generator

application or even biometric data.

The idea is to provide a second indication that you are who you claim to be. For example, forcing confirmation by responding to a cell phone text message or entering a PIN generated by a separate application.

No, this is not a replacement for secure credentials, but TFA does prevent lots of hackers from getting in through the front door.

It’s also a good idea to audit and analyze (even better with automation) what end users and administrators are doing – especially on critical systems and with critical data assets. Unfortunately, there are still many blind spots in this regard — especially in the realm of unstructured data. Luckily, there are commercial options for improving your detective controls.

Thanks! To summarize: while Kerberos is a better solution than NTLM, you should always have in place good IT security practices. And it’s not a bad idea to assume some hackers will eventually get in, and have a way to spot them when they do.

Kerberos is better. Many organizations, though, won’t be able to

implement it on a large scale for the reasons I mentioned earlier.

As a practical matter, your goal should cut your ties to NTLM v1 and

migrate to NTLM v2.

That’s it! It’s a good way to end this.

22The Essential Guide to Understanding Password-based Authentication

WORLDWIDE HEADQUARTERS

1250 Broadway, 31st Floor, New York, NY 10001 T 877-292-8767 E sales@varonis.com

UNITED KINGDOM AND IRELAND

Varonis UK Ltd. Warnford Court 29 Throgmorton Street London, UK EC2N 2AT T 020 3402 6044 E sales-uk@varonis.com

WESTERN EUROPE

Varonis France SAS 4, rue Villaret de Joyeuse 75017 Paris France T +33 (0)1.82.88.90.96 E sales-france@varonis.com

GERMANY, AUSTRIA AND SWITZERLAND

Varonis Deutschland GmbH Robert Bosch Strasse 7 64293 Darmstadt T +49-0-6151 2749070 E sales-germany@varonis.com

ABOUT VARONISVaronis is the leader in unstructured and semi-structured data governance software. Based on patented technology and a highly accurate analytics engine, Varonis solutions give organizations total visibility and control over their data, ensuring that only the right users have access to the right data at all times from all devices, all use is monitored, and abuse is flagged.

Varonis makes digital collaboration secure, effortless and efficient so that people can create and share content easily with whom they must, and organizations can be confident their content is protected and managed efficiently.

Free 30-day assessment:WITHIN HOURS OF INSTALLATION

You can instantly conduct a permissions audit: File and folder access permissions and how those map to specific users and groups. You can even generate reports.

WITHIN A DAY OF INSTALLATION

Varonis DatAdvantage will begin to show you which users are accessing the data, and how.

WITHIN 3 WEEKS OF INSTALLATION

Varonis DatAdvantage will actually make highly reliable recommendations about how to limit access to files and folders to just those users who need it for their jobs.