the security of the Chrome saved passwords depends totally on the user:

• Use a very strong Windows account password. Keep in mind, there are utilities which can decipher Windows passwords. If someone gets your Windows account password then they have access to your saved browser passwords.
• Protect yourself from malware. If utilities are able to easily access your saved passwords, why can’t malware?
• Save your passwords in a password management system such as KeePass. Of course, you loose the convenience of having the browser auto-fill your passwords.
• Use a 3rd party utility which integrates with Chrome and uses a master password to manage your passwords.

Q:

As far as I know, current versions of Mozilla Firefox store the saved passwords (encrypted with 3DES) to the logins.json file meanwhile the keys are stored in key4.db (or key3.db in older versions).

If one hasn't set up a Master Key for the passwords, the key database file can then be accessed. In the database, I've encountered an entry that does indeed look like the keys.

So, why possibly are there two 3DES keys in the database? Are they really encryption keys? How can I use them to decrypt the logins.json data? Which keying option is being used?

A:

In the data structure, item1 is the global salt, and item2 contains (in DER encoding) the entry salt and the encrypted key. This key is used to encrypt the rest of the data (per username and password).

The encryption of the master key is done with 3DES-CBC, with a key (and IV) derived from the master password, a global salt and a "per entry" salt. By default, the master password is the empty string. The password's entropy is bounded to 160 bits by sha1, which is further bounded to 112 bits by 3DES. The password is not hardened using multiple iterations of an hash.

The encryption of items (usernames and passwords) is done using 3DES-CBC, with an IV included in the metadata of each item. How IV is generated cannot be guessed from this source of the algorithm.

Unless the IVs are poorly generated, the small amount of data encrypted means that the best attack on 3DES is brute-forcing the master key or the user's password. The upper bound of 112 bits means that is this algorithm is considered weak by today standards: a big organization with huge resources might be able to brute-force the key in a few decades. Quantum computers might break them faster.

In practice, this means that a good, long passphrase must be used as the master password.

The RedLine information-stealing malware targets popular web browsers such as Chrome, Edge, and Opera, demonstrating why storing your passwords in browsers is a bad idea.

This malware is a commodity information-stealer that can be purchased for roughly $200 on cyber-crime forums and be deployed without requiring much knowledge or effort. //

While browser password stores are encrypted, such as those used by Chromium-based browsers, information-stealing malware can programatically decrypt the store as long as they are logged in as the same user. As RedLine runs as the user who was infected, it will be able to extract the passwords from their browser profile.

Tinker
@TinkerSec
A lot of folks think that this "patching" is "4D Chess" but it's really a basic behavior in a turf war.

The "turf" is your systems.

And you are not part of this "war".

I'll run through how it works and why unauthorized hackers do this as a standard TTP...

If you run a scan on your environment to see if you're patched for #log4j...

...and find that you are already patched.

Make sure you were the one that patched it.

Say I'm a mid level, decently skilled hacker.

I'm not a script kiddie. I have some experience. But, I'm not part of some nation state group or anything like that.

I just have a small bot net that I need to grow.

I see a major vuln w/a simple exploit like this #Log4J!

Awesome!

So I scan for vulnerable systems, find one, and hack into it.

But I find someone else is here!

This is normal. #Log4J is a hot topic right now. Everyone and their cat is hacking the internet.

What to do? I don't want this other hacker here.

I want this system to myself.

So I lay down a backdoor. Maybe a simple user account with root privileges accessible via SSH or maybe a backdoor implant that I have ready built.

I kick out the other hacker. Maybe by killing his connection process or system firewalling his IP.

Then...

Then... to make sure that hacker doesn't come back and to make sure that no other groups come in behind me by using the same #Log4J vulnerability that I used...

I patch the system.

I'm not patching the system to hide from sysadmins or to remove the system from some corporate patch management program.

I'm just covering my ass.

I'm just protecting my new found asset from other hackers.

This is my botnet now, so I need to maintain information security.

Tinker
@TinkerSec
·
13h
Alright, I'm officially over #Log4J.

Not saying anything in my org is patched.

Just saying I'm done worrying about it & am moving on w/my life.

Y'all need to stop living in fear.

Just accept that exploits happen & if it's your company's time to be breached, it's their time.

“The HSE assessed its cybersecurity maturity rating as low,” PWC wrote. “For example, they do not have a CISO or a Security Operations Center established.”

PWC also estimates that efforts to build up the HSE’s cybersecurity program to the point where it can rapidly detect and respond to intrusions are likely to cost “a multiple of the HSE’s current capital and operation expenditure in these areas over several years.” //

“The term ‘Security Maturity’ refers to the street smarts of an individual or organization, and this maturity generally comes from making plenty of mistakes, getting hacked a lot, and hopefully learning from each incident, measuring response times, and improving.

Let me say up front that all organizations get hacked. Even ones that are doing everything right from a security perspective get hacked probably every day if they’re big enough. By hacked I mean someone within the organization falls for a phishing scam, or clicks a malicious link and downloads malware. Because let’s face it, it only takes one screw up for the hackers to get a foothold in the network.

Now this is in itself isn’t bad. Unless you don’t have the capability to detect it and respond quickly. And if you can’t do that, you run the serious risk of having a small incident metastasize into a much larger problem.

Think of it like the medical concept of the ‘Golden Hour:’ That short window of time directly following a traumatic injury like a stroke or heart attack in which life-saving medicine and attention is likely to be most effective. The same concept holds true in cybersecurity, and it’s exactly why so many organizations these days are placing more of their resources into incident response, instead of just prevention.”

Why not just use C and C++? The reason is security and memory-related bugs, said Lerche, quoting research that “70 per cent of all high severity security vulnerabilities in software in C and C++ are due to [lack of] memory safety.”

Rust is revolutionary, he said, because “Rust is the first mainstream programming language that is efficient while maintaining memory safety.” Lerche explained how Rust achieves memory safety by using the idea of ownership, based on a concept called Affine logic, where each object has one and only one owner at a time.

Ownership rules are checked at compile time, so there is no runtime overhead. Concurrency too is easier and safer in Rust than in C or C++, leading to further performance and efficiency gains. //

The problem is that coding in Rust is hard. One reason why languages like Java, JavaScript, and Python have seen such wide adoption is that programmers can become productive more quickly.

This then is the elephant in the room, “the famous learning curve,” said Miller. In a recent survey, “of the engineers who said they were no longer using the language, 55 per cent cited learning and productivity as their reason for abandoning it. Experienced engineers require three to six months of study supported by a subject matter expert before they are productive with the language.”

A hacker stole $31 million from the blockchain company MonoX Finance, by exploiting a bug in software the service uses to draft smart contracts.

The article goes on to talk about how common these sorts of attacks are. The basic problem is that the code is the ultimate authority — there is no adjudication protocol — so if there’s a vulnerability in the code, there is no recourse. And, of course, there are lots of vulnerabilities in code.

To me, this is reason enough never to use smart contracts for anything important. Human-based adjudication systems are not useless pre-Internet human baggage, they’re vital.

Criminal groups have been sending threatening messages in the past couple of months to companies that manage broadband phone services all over the world, promising they'll flood the digital phone lines with traffic and take them offline unless victims pay a ransom.

What those extortionists have discovered is that the number of phone calls that take place at least partially over the internet has quietly and dramatically increased over recent years — and there's a lot at stake when major providers go down. //

if there were going to be a kinetic war with an adversary — Russia, North Korea, Iran, whatever — look how fragile this is that some probably teenage kids with a botnet are able to take out major communication providers and demand ransoms from them," Wisniewski says. "What if it was a sophisticated, well equipped adversary like a nation state could wipe out our communication in minutes?"

In telecommunications circles there is a truism that is so constant it’s a reality in it’s own right,

“Standards are like toothbrushes. Every one agrees that you should have one and everyone agrees you should use it religiously. But even when they don’t have one of their own nobody else ever wants to use yours.”

Imagine being able to disconnect or redirect Internet traffic destined for some of the world’s biggest companies — just by spoofing an email. This is the nature of a threat vector recently removed by a Fortune 500 firm that operates one of the largest Internet backbones. //

For a long time, any changes to an organization’s routing information with an IRR could be processed via email as long as one of the following authentication methods was successfully used:

• A password is added to the text of an email to the IRR
• The requestor signs the email containing the update with an encryption key
• The requestor sends the record changes in an email to the IRR, and the authentication is based solely on the “From:” header of the email.

Of these, MAIL-FROM has long been considered insecure, for the simple reason that it’s not difficult to spoof the return address of an email. And virtually all IRRs have disallowed its use since at least 2012, said Adam Korab, a network engineer and security researcher based in Houston.

All except Level 3 Communications, a major Internet backbone provider acquired by Lumen/CenturyLink.

“LEVEL 3 is the last IRR operator which allows the use of this method, although they have discouraged its use since at least 2012,” Korab told KrebsOnSecurity. “Other IRR operators have fully deprecated MAIL-FROM.”

Importantly, the name and email address of each Autonomous System’s official contact for making updates with the IRRs is public information. //

Lumen told KrebsOnSecurity that it continued offering MAIL-FROM: authentication because many of its customers still relied on it due to legacy systems. Nevertheless, after receiving Korab’s report the company decided the wisest course of action was to disable MAIL-FROM: authentication altogether. //

While it’s nice that Lumen is no longer the weakest link in the IRR chain, the remaining authentication mechanisms aren’t great. Claffy said after years of debate over approaches to improving routing security, the operator community deployed an alternative known as the Resource Public Key Infrastructure (RPKI).

“The RPKI includes cryptographic attestation of records, including expiration dates, with each Regional Internet Registry (RIR) operating as a ‘root’ of trust,” wrote Claffy and two other UC San Diego researchers in a paper that is still undergoing peer review. “Similar to the IRR, operators can use the RPKI to discard routing messages that do not pass origin validation checks.”

However, the additional integrity RPKI brings also comes with a fair amount of added complexity and cost, the researchers found. //

Dave
November 26, 2021

The problem with RPKI as a security mechanism is that they handed the problem of securing BGP over to a bunch of X.509 fanboys, and so the result was something that looked suspiciously like X.509…. no, I stand corrected, it is X.509. It’s an attempt to use an X.509 certificate in a way that was never designed for, combined with the mass of other problems that make X.509 such a joy to use.

“The East India Company was no apparition though; it was the template for many subsequent corporations […] Liberals betray themselves […] the moment they turn a blind eye to this kind of hyper-concentrated power. […] This is why trading in apples does not come even close to trading in shares. Large quantities may produce, at worse, lots of bad cider, but large amounts of money invested in liquid shares can release demonic forces that no market or state can control.”
― Yanis Varoufakis, Another Now: Dispatches from an Alternative Present

Built of cobbled hubris and copied code we sail a vast uncharted ocean of extremely hungry sharks, no “plan” at any point but sink or swim, and no rudder. Greater speed the only virtue and destination. You can imagine how it goes, when it does. The looks on people’s faces in the inconvenient reality. Wherever this course leads, faster. More coal to the boilers now. Release date approaches.

Many security-conscious people probably think they’d never fall for a phone-based phishing scam. But if your response to such a scam involves anything other than hanging up and calling back the entity that claims to be calling, you may be in for a rude awakening. //

Mitch’s bank managed to reverse the unauthorized wire transfer before it could complete, and they’ve since put all the stolen funds back into his account and issued a new card. But he said he still feels like a chump for not observing the golden rule: If someone calls saying they’re from your bank, just hang up and call them back — ideally using a phone number that came from the bank’s Web site or from the back of your payment card. As it happened, Mitch only followed half of that advice.

There was a time when I was content to let my bank authenticate me over the phone by asking for some personal identifiers (SSN/DOB) that are broadly for sale in the cybercrime underground. At some point, however, I decided this wasn’t acceptable for institutions that held significant chunks of our money, and I began taking our business away from those that wouldn’t let me add a simple verbal passphrase that needed to be uttered before any account details could be discussed over the phone.

Most financial institutions will let customers add verbal passwords or personal identification numbers (PINs) that are separate from any other PIN or online banking password you might use, although few will advertise this.

Even so, many institutions don’t properly train their customer support staff (or have high turnover in that department). This can allow clever and insistent crooks to coax customer service reps into validating the call with just the SSN and/or date of birth, or requiring the correct answers to so-called knowledge-based authentication (KBA) questions. //

A few years ago, I began testing financial institutions that held our personal assets. I was pleasantly surprised to discover that most of them were happy to add a PIN or pass phrase to the account. But many of the customer service personnel at those institutions failed in their responses when I called in and said I didn’t remember the phrase and was there any other way they could verify that I was me?

Ultimately, I ended up moving our investments to an institution that consistently adhered to my requirements. Namely, that failing to provide the pass phrase required an in-person visit to a bank branch to continue the transaction, at which time ID would be requested. Their customer service folks consistently asked the right questions, and weren’t interested in being much helpful otherwise (I’m not going to name the institution for obvious reasons).

Not sure whether your financial institution supports verbal passwords? Ask them. If they agree to set one up for you, take a moment or two over the next few days to call in and see if you can get the customer service folks at that institution to talk about your account without hearing that password. //

Even if your institution offers voice biometrics, adding a verbal password/passphrase is still a good idea.

One of the more common ways cybercriminals cash out access to bank accounts involves draining the victim’s funds via Zelle, a “peer-to-peer” (P2P) payment service used by many financial institutions that allows customers to quickly send cash to friends and family. Naturally, a great deal of phishing schemes that precede these bank account takeovers begin with a spoofed text message from the target’s bank warning about a suspicious Zelle transfer. What follows is a deep dive into how this increasingly clever Zelle fraud scam typically works, and what victims can do about it.

Last week’s story warned that scammers are blasting out text messages about suspicious bank transfers as a pretext for immediately calling and scamming anyone who responds via text.

Anyone who responds “yes,” “no” or at all will very soon after receive a phone call from a scammer pretending to be from the financial institution’s fraud department. The caller’s number will be spoofed so that it appears to be coming from the victim’s bank.

To “verify the identity” of the customer, the fraudster asks for their online banking username, and then tells the customer to read back a passcode sent via text or email. In reality, the fraudster initiates a transaction — such as the “forgot password” feature on the financial institution’s site — which is what generates the authentication passcode delivered to the member.

Ken Otsuka is a senior risk consultant at CUNA Mutual Group, an insurance company that provides financial services to credit unions. Otsuka said a phone fraudster typically will say something like, “Before I get into the details, I need to verify that I’m speaking to the right person. What’s your username?”

“In the background, they’re using the username with the forgot password feature, and that’s going to generate one of these two-factor authentication passcodes,” Otsuka said. “Then the fraudster will say, ‘I’m going to send you the password and you’re going to read it back to me over the phone.'”

The fraudster then uses the code to complete the password reset process, and then changes the victim’s online banking password. The fraudster then uses Zelle to transfer the victim’s funds to others.

An important aspect of this scam is that the fraudsters never even need to know or phish the victim’s password. By sharing their username and reading back the one-time code sent to them via email, the victim is allowing the fraudster to reset their online banking password. //

“Consumers — many who never ever realized they had a Zelle account – then call their banks, expecting they’ll be covered by credit-card-like protections, only to face disappointment and in some cases, financial ruin,” Sullivan wrote in a recent Substack post. “Consumers who suffer unauthorized transactions are entitled to Regulation E protection, and banks are required to refund the stolen money. This isn’t a controversial opinion, and it was recently affirmed by the CFPB here. If you are reading this story and fighting with your bank, start by providing that link to the financial institution.”

“If a criminal initiates a Zelle transfer — even if the criminal manipulates a victim into sharing login credentials — that fraud is covered by Regulation E, and banks should restore the stolen funds,” Sullivan said. “If a consumer initiates the transfer under false pretenses, the case for redress is more weak.” //

Anyone interested in letting the CFPB know about a fraud scam that abused a P2P payment platform like Zelle, Cashapp, or Venmo, for example, should send an email describing the incident to BigTechPaymentsInquiry@cfpb.gov. Be sure to include Docket No. CFPB-2021-0017 in the subject line of the message.

In the meantime, remember the mantra: Hang up, Look Up, and Call Back. If you receive a call from someone warning about fraud, hang up. If you believe the call might be legitimate, look up the number of the organization supposedly calling you, and call them back.

For those who want to lock things down without going offline and moving to a bunker in New Zealand, the first step is to assess the following things:

• What in my digital life can give away critical information tied to my finances, privacy, and safety?
  • What can I do to minimize those risks?
  • How much risk reduction effort is proportional to the risks I face?
  • How much effort can I actually afford?

First, if you're not at home, you should always lock your device before you put it down, no exceptions. Your phone should be locked with the most secure method you're comfortable with—as long as it's not a 4-digit PIN, which isn't exactly useless but is definitely adjacent to uselessness. For better security, use a password or a passcode that's at least six characters long—and preferably longer. //

Second, set your device to require a password immediately after it’s been locked. //

Also, regularly back up your phone. //

[Don't install bad apps -- consider carefully where it comes from, what it does, if you really need it.] //

Consider turning off Wi-Fi when you’re away from home. Your device may otherwise be constantly polling for the network SSIDs in its history to reconnect automatically or to connect to anything that looks like a carrier’s Wi-Fi network. When this happens, your device gives away information about networks you’ve seen and might allow a hostile network access point to connect. Also, your phone's Wi-Fi MAC address could be used to fingerprint your device and track it. //

The same goes for Bluetooth. If your device has Bluetooth turned on, it’s broadcasting information that could identify it—and you. //

Along those same lines, name your device anything other than [Your Name]’s iPhone. Your phone's network name is broadcast all around you, and it's like holding up a beacon saying "Hello, my name is..." //

[Malware protection on your PC] Even allowing Windows Defender to run in the background provides a significant bump in protection over nothing, and disabling it without a very good reason is a very bad idea. //

[Keep your OS & software up to date -- install updates as soon as they are available ]

[Turn on Windows Firewall when in public]

In the event that your physical device is compromised, you can minimize damage by caring for your actual data. To prevent all types of data loss, back up your data—in encrypted form and offline (either locally or in the cloud) so that ransomware doesn’t get the backups, too. Keep multiple backups just in case, because if your latest backup contains the compromised or encrypted files, it's useless.

And don't just back up your data, use full-disk encryption. Period. It's a one-time setting to activate and there are no excuses for not using it. Full-disk encryption transparently encrypts your hard drive so data can’t be read off of it without your credentials. //

Wi-Fi access points and routers that support firmware or software updates add another layer to the security of your devices while web browsing. If you have an older Wi-Fi access point that you can’t update, toss it. //

And, finally, use a password manager. An easy-to-guess password renders all other security efforts moot. Whether it’s a password built into your web browser of choice or a standalone program, use one. Chrome, Firefox, and Safari all have reasonably secure password managers, and you can replicate passwords for web accounts across devices. If you don't like the idea of a password manager because you're one of those folks who just uses letmein123! as your password everywhere, you need to decide if the convenience is worth the price you'll eventually pay when you're compromised. (Spoiler alert: it's not.)

You can do a number of things to reduce the risks posed by data breaches and identity fraud. The first is to avoid accidentally exposing the credentials you use with accounts. A data breach of one service provider is especially dangerous if you haven’t followed best practices in how you set up credentials. These are some best practices to consider:

• Use a password manager

• When possible, use two-factor or multi-factor authentication ("2FA" or "MFA"). This combines a password with a second, temporary code or acknowledgment from someplace other than your web browser or app session. Two-factor authentication ensures that someone who steals your password can’t use it to log in. If at all possible, don’t use SMS-based 2FA, because this is more prone to interception.

• Set up a separate email address or email alias for your high-value web accounts so that all email regarding them is segmented off from your usual email address. This way, if your primary email address is caught up in a data leak, attackers won’t be able to use that address to try to log in to accounts you care about.

• If you're a US resident, make sure to claim an account for your Social Security number from the IRS for tax information access and other purposes.

• Consider locking your credit reports to reduce identity theft risks.

My company policy states I must put all passwords in a password safe shared with management. Is this secure?

As the title says, my company has a policy that all passwords to e.g. our workstations and server logins must be stored in an online safe. I won't say which one but there are some out there you can look at promising the end of password pain. These passwords are then shared with the company's management - I don't know how that bit works, but they can read the passwords too. //

None of the reasons you've given are valid reasons for escrowing your password. There's only a couple valid reasons for escrowing any sort of "authenticator" information. A couple others have touched on these, but I'll try to clarify a bit.

1. Encryption Keys: It makes absolute sense for the organization to have access to escrow copies of your encryption keys. After all, the data you're encrypting (provided you're only using your company's encryption for work purposes, of course) is their data in the end anyway. So, they need to retain access to that data in the event you lose your key or you are separated from the company. However, the encryption key should not be the same key you use for digital signatures. Also, they should not have actual access to your authenticator - the passcode you use for the key. Instead, they should have their own escrow key that works with their authenticator to decrypt your data.

2. Failsafe Accounts: It also makes sense that the organization should have backup copies of credentials necessary to access an Administrator-level account in the event the System Administrator's own account is locked out, or they depart the company. However, the credentials should not be for the System Administrator's own account. They should be for a local system account whose sole purpose is for emergency use. To that end, the account should also never be used for non-emergencies and its usage should be closely monitored and alerted. Traditionally, credentials for accounts like these are sealed in tamper-evident envelopes and stored in a secure, physical vault. It's conceivable that there may be digital equivalents, but I personally wouldn't trust those without a thorough review.

There's two big reasons why it's a bad idea for management to have your password. The first reason is potentially very bad for you, as it could end up causing otherwise unnecessary work for you if things go wrong. However, the second actually turns this around and makes it potentially worse for the company than it is for you if things go really wrong.

1. Potential For Abuse: The obvious one - managers now effectively have unrestricted access to the systems, regardless of whether they should, with the same privileges you have. Most simply this means that the managers may leverage this to do things on the system that they otherwise should not be doing. This also leaves the potential for them to bypass your position whenever they want to rush a particular change along without following standard procedure.

2. Loss of Non-Repudiation: Once someone else has your credentials - and, especially in a case like this where it can be proven they do - they can impersonate you on any systems where those credentials are valid. This makes it difficult to definitively prove that any actions taken by your account were actually taken by you. If a manager does decide to use your account, and ends up royally screwing up the system, it won't be very easy to use you as a scapegoat even though your account is in the logs. Worse for the company is, if you do something to royally screw up the system while your managers have your password, they'll have a harder time proving that it was actually you that did it.

TL;DR: There's no good reason I can think of for management to have any of your passwords. As for the reasons they've given:

1. "If you forget your password..." another System Administrator can reset it for you. Or, management can "break the glass" on the emergency account (see "Failsafe Accounts" above) and do it themselves.
2. "If you turn evil..." again you can be locked out by another System Administrator, or the emergency account. //

No, it is not a good idea. Thomas explained why it doesn't achieve its own goals, but it is worse than that.

Consider what happens when a rogue employee misbehaves causing damage to the company.

During the trial, you are subpoenaed to testify about logs showing that it was the employee who caused the damage, and are asked who else could log in as this employee. You truthfully answer that anyone with access to the safe including all of management could log in as that employee and your logging systems would be none the wiser.

Anything that blurs the distinction between actor and authenticating credentials seriously undermines the company's ability to use access logging to discourage misbehavior or recoup damages.

Managers often hand out passwords to subordinates when an IBAC system fails to explicitly handle delegation, but this is the reverse of that case, where the blurring affects the credentials of the much larger group of lower-level employees.

Appendix A of NIST 800-63B addresses this well. Avoiding password patterns is specifically why they recommend against arbitrary password complexity requirements and arbitrary password expiration times. Passwords should only be force expired on events. Timed expiration and complexity rules encourage patterns that make the password weaker. //

Levenshtein distance as a proxy for password strength is extremely limited, for the reasons that schroeder has outlined. And the user experience will probably be poor.

But the question is still academically interesting, and may be useful as a component for some use cases - so it still deserves a thorough answer. :D

Generally, the minimum Levenshtein distance between a previous password and a new one should be the same size as the minimum length of a randomly-generated password that would resist brute force (adjusted to the attacker's threat model). But it's important to note that even this minimum is often inadequate. //

Best case - the passwords are entirely randomly generated, both initially and later. In this case, Levenshtein distance isn't as relevant (or rather, measuring the Levenshtein distance between two randomly generated passwords is just a proxy for measuring the quality of their randomness). //

If we assume all worst cases (human-generated password, poor password-selection strategy, etc.), the answer should be clear: the amount of change in the password should itself be enough to withstand attack on its own - totally independent of the previous password (as if the first password was empty), and as if it was stored using a very fast hash like MD5. This is reduced to how fast we can reasonably expect a randomly generated password to be exhausted for a given threat model, and is covered well elsewhere (but can often hover around 13-15 random characters). //

In other words ... just like Shannon entropy, usefulness of Levenshtein distance as a measure of password strength is really only useful in cases where the passwords are already randomly generated. And if you're doing that, you already have the information necessary to keep them strong, without trying to measure the difference between two of them.

In even other words ... very low Levenshtein distances are an OK proxy for password change weakness, but high Levenshtein distances are a very poor proxy for password change strength. So my answer tries to find a balance between the two.

ebooks on Linux topics

karalabe commented May 2, 2017

TL;DR https://play.golang.org/p/LPkPTRF7fC

The above code looks quite plain and obvious, except it does something completely different than you'd expect (feel free to run it). The obvious thing that should happen is that it counts the number of bits set in the given string. The non-obvious thing that happens is that the mask is actually 0, not 0x01.

So, what happened there? The abuse in the above code is around the invisible Unicode characters that mark following text to be right-to-left or left-to-right. Since Go permits arbitrary Unicode characters to be present in string literals, it also allows me to have a string of the form "bla bla blaabc". Since we're dealing with valid Unicode sequences here, any modern editor/website will actually interpret those special characters, causing the content in between the two special marks to be reversed to the end of the line (alas still part of the string literal).

In my playground code this is abused by having the following source code:

 str, mask := "Hello, World!<rtl>10x<ltr>", 0

Which will be displayed by all modern editors/websites as:

 str, mask := "Hello, World!", 0x01

The security aspect of this issue is social engineering attacks. The "display" line of my sample code is obvious beyond doubt, so noone will ever inspect such a thing; however it managed to flip one bit in a mask (imagine doing this for file permission umasks). The issue is that such code could easily get past reviews and into a final product.