413 private links
Password security and a comparison of Password Managers
There are two general approaches to password generation and management:
Password Managers which store passwords and have the flexibility to apply different complexity rules to each password or to store a pre-existing password - often required when a password needs to be shared between a team of people. The downside of the storage approach is that the password storage (file/database) needs to be managed carefully - secured, backed up and synchronised to all the devices where you will need to use the passwords. If the password store is lost or corrupted you will lose all the passwords! Destructive viruses such as CryptoLocker can also make a password store unreadable.
Password Generators which use a hash function, like the SS64 password generator, are easy to use and will repeatedly regenerate the same password when given the same inputs but they do have some limitations, the only way to change a password is to enter a different main password or a different salt value. All the generated passwords are the same length. //
NIST recommend 80 bits for the most secure passwords to resist a brute force attack. There is no definitive answer to the question of the minimum password strength required to avoid all types of attack; it is a moving target; over time we all need to use longer passwords.
Entropy Maximum Time to crack at 350 billion guesses/Sec
59 bits 457.50 Hours
65 bits 3.342 Years
71 bits 213.92 Years
77 bits 13,690 Years
80 bits 109,527.95 Years
89 bits 56078315.93 Years.
GPU computer clusters can cycle through as many as 350 billion guesses per second. [offline guesses against a stolen password database/file]
Kerckhoffs’s principle - A cryptosystem should be secure even if everything about the system, except the key, is public knowledge
A 2FA Mule is a mobile phone configured to forward SMS 2FA codes via email.
This divorces 2FA from the mobile phone you carry with you and makes it possible to perform 2FA without your phone, after having your phone lost or stolen, while on an airplane, or while roaming in a foreign place with an alternate SIM card.
In my case, the 2FA mule sits in my office lab connected to mains power.
It is an unlocked Google Pixel phone with no google account and no apps installed except for "SMS Forwarder".
It is configured to forward all SMS to an email address via encrypted SMTP.
jhollinger said:
Sounds like this may explain the large number of password reset requests I'm suddenly getting...
My sisters instagram account was taken over before, interesting strategy they use.
Basically they start chit chatting with you about your posts to look friendly, then they message you saying that someone is trying to hack their account and send you pics of the reset text that instagram sends out and ask if you received anything similar.
In the background they try to reset your account and then you receive the text from instagram to recover it, then you obviously tell them yes i'm receiving the same texts, they ask for a screenshot of it to compare with their own which has a link to recover the account. Then they simply type in the link, make a new password and have access to the account.
My sister didn't have 2fa on because she used some other app to see who follows/unfollows her and it didn't work with 2fa, she eventually got her account back and learned her lesson... i hope lol
Passkeys are an asymmetric key pair
Each passkey is a pair of two related asymmetric cryptographic keys, which are very long, random strings of characters. While they differ from each other, they do have a special relationship - one can decrypt messages that have been encrypted by the other. This feature can be used to verify a user and authenticate them.
The key pair is made up of a private key that’s kept securely on your device, inside a password manager supporting passkeys (also called a passkey provider), and a public key that’s stored on the website you are logging into. Your private key is secure and never leaves your device, and the password manager keeps it locked by biometrics, PIN, or a password. The public key, on the other hand, could be shared with the world, such as in the case of a website data breach, and your security wouldn't be compromised so long as the private key stays safe.
In November 2022, the password manager service LastPass disclosed a breach in which hackers stole password vaults containing both encrypted and plaintext data for more than 25 million users. Since then, a steady trickle of six-figure cryptocurrency heists targeting security-conscious people throughout the tech industry has led some security experts to conclude that crooks likely have succeeded at cracking open some of the stolen LastPass vaults. //
How hard would it be for well-resourced criminals to crack the master passwords securing LastPass user vaults? Perhaps the best answer to this question comes from Wladimir Palant, a security researcher and the original developer behind the Adblock Plus browser plugin.
In a December 2022 blog post, Palant explained that the crackability of a LastPass master password depends largely on two things: The complexity of the master password, and the default settings for LastPass users, which appear to have varied quite a bit based on when those users began patronizing the service.
LastPass says that since 2018 it has required a twelve-character minimum for master passwords, which the company said “greatly minimizes the ability for successful brute force password guessing.”
But Palant said while LastPass indeed improved its master password defaults in 2018, it did not force all existing customers who had master passwords of lesser lengths to pick new credentials that would satisfy the 12-character minimum.
“If you are a LastPass customer, chances are that you are completely unaware of this requirement,” Palant wrote. “That’s because LastPass didn’t ask existing customers to change their master password. I had my test account since 2018, and even today I can log in with my eight-character password without any warnings or prompts to change it.”
Palant believes LastPass also failed to upgrade many older, original customers to more secure encryption protections that were offered to newer customers over the years. One important setting in LastPass is the number of “iterations,” or how many times your master password is run through the company’s encryption routines. The more iterations, the longer it takes an offline attacker to crack your master password.
Palant noted last year that for many older LastPass users, the initial default setting for iterations was anywhere from “1” to “500.” By 2013, new LastPass customers were given 5,000 iterations by default. In February 2018, LastPass changed the default to 100,100 iterations. And very recently, it upped that again to 600,000.
Palant said the 2018 change was in response to a security bug report he filed about some users having dangerously low iterations in their LastPass settings.
“Worse yet, for reasons that are beyond me, LastPass didn’t complete this migration,” Palant wrote. “My test account is still at 5,000 iterations, as are the accounts of many other users who checked their LastPass settings. LastPass would know how many users are affected, but they aren’t telling that. In fact, it’s painfully obvious that LastPass never bothered updating users’ security settings. Not when they changed the default from 1 to 500 iterations. Not when they changed it from 500 to 5,000. Only my persistence made them consider it for their latest change. And they still failed implementing it consistently.”
FusionAuth is the customer authentication and authorization platform that makes developers' lives awesome. You'll get all the features your app needs plus a customizable, scalable solution you can run on any computer, anywhere in the world.
If a transgression by a single employee breaches your network, you're doing it wrong. //
Accessing personal accounts at a company like Okta has long been known to be a huge no-no. And if that prohibition wasn’t clear to some before, it should be now. The employee almost surely violated company policy, and it wouldn’t be surprising if the offense led to the employee’s firing.
However, it would be wrong for anyone to conclude that employee misconduct was the cause of the breach. It wasn’t. The fault, instead, lies with the security people who designed the support system that was breached, specifically the way the breached service account was configured. //
First, Okta should have put access controls in place besides a simple password to limit who or what could log into the service account. One way of doing this is to put a handful of company-controlled IP addresses on an allow list and to block all others unless additional credentials are supplied. Another is to regularly rotate access tokens used to authenticate to service accounts. And, of course, it should have been impossible for employees to be logged in to personal accounts on a work machine. These and other precautions are the responsibility of senior people inside Okta.