You are not connected. The newsletter may include some user information, so they may not be displayed correctly.

LastPass Data Breach, Repatriation from the Big Cloud and Password Policy

LastPass Data Breach, Repatriation from the Big Cloud and Password Policy

‍VMsources

‍Secure Cloud and Business Continuity

‍Thursday, 22 February 2024 04:41 ‍

 

Hello  ‍,

 

Happy New Year. I wanted to cover the LastPass Data Breach in practical terms, talk about password policy, and cover repatriation from the Big Cloud using a customer success story which we completed in 2022.

 

Our monthly newsletter is very simple this month:

  1. LastPass Data Breach
  2. Repatriation from the Big Cloud
  3. Practical Password Policy

Please contact me directly if you have any needs or questions; remember the buck stops here!

 

Your Business Continuity Specialist,

 

John Borhek

CEO, Lead Solution Architect

VMsources Group Inc.

Mobile: +1 928.606.0483

Direct-dial office: +1 928.864.0850

Email: john@vmsources.com

Website: https://vmsources.com


1. LastPass Data Breach

Most of you already know LastPass was breached and Threat Actors have stolen customers data including password vaults and unencrypted data including the IP addresses and URLs from which the Vault was accessed. This not only provides Thread Actors with the unlimited opportunity to brute-force the master vault password but also the ability to cherry-pick valuable targets and even go after the clients of LastPass account holders!

What this means:

Since the Threat Actors already have the vault, there are no mechanisms to stop them from using brute-force password attempts at the maximum frequency which their technology will support, and they likely have dedicated CPU and GPU systems for cracking passwords. If your master vault password was less than 13 characters at the time of the data breach, Threat Actors may have already gained access to your vault.

Amount of time to brute-force a password

If your master vault password length is described in any of the red cells, it’s time to change all passwords which were recorded in the vault!

 

Number of Characters

Lowercase Letters

Lower and Upper case letters

Lower and Upper case letters, Numbers

Lower and Upper case letters, Symbols, Numbers

8

Instantly

1 Minutes

7 Minutes

39 Minutes

9

Instantly

1 Hour

7 Hours

48 Hours

10

4 Minutes

72 Hours

21 Days

120 Days

11

2 Hours

2 Months

3 Years

34 Years

12

48 Hours

20 Years

200 Years

3000 Years

LastPass Replcaement

Proprietary solutions (even those “based on Open Source”) have closed code, which has been reviewed only by a very specific and limited number of individuals. No matter how talented those individuals, history proves that there are always opportunities for Threat Actors to exploit.

 

For a password manager/vault, VMsources strongly recommends Open Source solutions over proprietary software. It’s simple: Open Source solutions are constantly being reviewed for vulnerabilities, not only be their developers, but by the entire world! Vulnerabilities are usually discovered and fixed in beta, but even when they do make it to GA on Open Source, the frequency is a tiny fraction of what is seen with Proprietary software.

 

We use and recommend KeePass password manager, hosted internally on your own systems as the best choice for a password manager, and don’t forget to use a complex password 13 or more characters in length, or none of this makes any difference!

We have also written a Whitepaper on using KeePass to help you get started.

 

At VMsources, we always do what’s right for the customer, even if it’s not the most profitable solution we could recommend. We’re also available to help you install KeePass in your environment in the event you would like a little help in getting set-up.


2. 2023 is the year of repatriating Big Cloud workloads 

Last year a Client called me with a problem. They had migrated workloads to the Big Cloud, but costs were getting out-of-hand.

 

Even though Client had carefully done their due-diligence with all of the tools provided by their chosen Big Cloud, their best TCO estimates for the Big Cloud turned out to be only about 30% of the actual cost, and the cost was increasing monthly at an alarming rate based on obscure and unmeasurable things like “block-blobs”!

 

Client wanted to repatriate, but there was a problem; on-premises server and storage hardware where VMware vSphere was running was at EOL because Management had previously indicated moving in the direction of the Big Cloud – until Management saw what Big Cloud actually cost!

 

Now Client was between a rock and a hard place, the big cloud cost WAY more than Client had told Management, and on-premises systems were no longer desirable for hosting the workloads which had been migrated to the Big Cloud.

 

That’s when Client called me and I told them about our dedicated VMware vCloud with SOC 1 and SOC II certification (plus ISO, NIST, HIPAA, PCI and more), 3-2-1 Backup Rule compliance and certification, and built-in trans-continental DRaaS.

 

The advantage of our VMware vCloud, aside from vastly improved service and a best-in-business SLA, is that we offer a fixed and guaranteed TCO based on allocated resources, with unlimited usage of those resources at no extra cost.

  • Fixed and guaranteed TCO for the duration of the contract.
  • No data-transform required to gain optimum efficiency.
  • Compute cost based on allocated resources and not usage.
  • About half the cost of Amazon and other Big Clouds.
  • No overage or surcharges ever.
  • Control the ever-increasing cost of IT.
  • Fully managed migration from the Big Cloud or on-premises workloads.
  • About half the cost of the Big Cloud.
  • Veeam and VMware vCloud to the rescue.

Because we are a Certified Veeam Partner, VMsources has all of the tools at our disposal to ensure a seamless and fully-managed migration from on-premises workloads to our VMware vCloud -OR- to repatriate workloads from the Big Cloud to our VMware vCloud.


Veeam is fully software-defined and platform-agnostic, it is suitable for all types of migration as well as Backup as a Service BaaS and Disaster Recovery as a Service DRaaS:

  • Migration & repatriation from the Big Cloud.
  • Migration from on-premises.
  • Backups of VMware vSphere, Hyper-V, Nutanix AHV.
  • Disaster recovery for VMware vSphere, Hyper-V, Nutanix AHV.
  • Backups from o365 (take ownership of your data and retention).
  • Planned and tested Disaster Recovery.

Clients migration from Big Cloud to our VMware vCloud was completely successful and, with the addition of several servers to the environment. Furthermore, Client had not specified any availability zones in the Big Cloud and backup retention was set at 7 days to reduce costs. In the end, the Clients total bill came to about half of what they had been paying in the Big Cloud with trans-continental DRaaS and our usual policy of 30-days plus 12 months of backup retention.


Give me a call directly is you would like to speak directly to “Client,” or any of our excellent real-world references for VMware vCloud and DRaaS.

 

We believe your Cloud should know you as well as you know your Cloud!

 


3. Practical Password Policy 

Password recommendations is by NIST

The NIST issued Special Publication 800-63B, debunking many of the counterproductive policies foisted upon us by auditors and administrators concerned more with the “letter-of-the-law” that actual security.

The DOs and DONTs:

The NIST uses the unambiguous terminology of “SHALL” and “SHALL NOT” in Special Publication 800-63B. In this article, I have attempted to distill the NIST recommendations to those points which apply directly to Kerberos based user directories such as Active Directory. Many of the recommendations below are directly contradictory to current policies and should be updated immediately.

 

Don’t forget, if you are running vCenter, you have a separate Kerberos directory known as vSphere SSO. Your SSO Directory contains at least one user, and those policies should be updated concurrently with AD to meet NIST guidelines.

The DO’s

• DO use multi-factor authentication


• NIST Says (4.2.1) authentication SHALL occur by the use of either a multi-factor authenticator or a combination of two single-factor authenticators.


• DO allow use of passphrases


• NIST Says (5.1.1.2): “Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets.”


• DO allow the use of cut & paste for passwords


• NIST Says (5.1.1.2): “Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret.”


• DO favor users, not administrators


• NIST Says (6.1.3): “password policies should be user friendly and put the burden on the verifier”


• DO enforce password length


• NIST Says (5.1.1.1) “Memorized secrets SHALL be at least 8 characters in length”


• DO create a banned-list and compare passwords to known-bad passwords


• NIST Says (5.1.1.2): “compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised”


• DO enforce timeout for inactivity


• NIST Says (4.3.4): “Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 15 minutes or longer”


• DO allow users to see their passwords in plain text


• NIST Says (5.1.1.2): “offer an option to display the secret — rather than a series of dots or asterisks — until it is entered”

The DO NOT’s

• DO NOT require numbers, special characters or enforce composition rules


• NIST Says (5.1.1.2): “Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.”

 

• DO NOT use hints or questions


• NIST Says (5.1.1.2): “Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”)

 

• DO NOT enforce password aging

 

• NIST Says (5.1.1.2): “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”

 

No Big Cloud will offer the level of service you will get from VMsources!

 

‍Unsubscribe ‍

 +1 866 644 7764