201–210 of 288 posts
Earlier quoted context omitted.
Special character requirements normally end with most people adding # to the end of their dictionary vulnerable password, plus a lot more of valid password reset requests that could hide phishing attacks.
#, really? The one I see most often is an exclamation mark!
Perhaps surprisingly, US government guidelines exist, are pretty fantastic, and agree with the author: Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of c…
6 characters in length seems a bit shoddy.
For many systems, users can memorize 6 digits easily.
The reality is, whatever your password reset flow is is enough. If you can reset your password with a 6 digit number via text, then that is maximum needed for actual password as well in most cases.
So, really, you should change a password regularly if: - The password is weak - It is ever reused - Anyone else has access to it - You use it on a device you don't control - You use it on a device which might be running malware and can intercept it - It was stored insecurely
While sharing passwords is never a good idea, sometimes it is necessary. For example, I am the treasurer of a non-profit organization, an elected position that rotates every two years. We have a savings account at a credit union that for a variety of reasons requires online access by multiple individuals who change over time. The only way to keep this even a little secure over time is to require a password change every time someone drops off the authorized access list.
There could also be software licensing issues that lead to multiple users sharing a login for software, same thing applies.
Earlier quoted context omitted.
I worked on Identity, Credentialing and Access Management (ICAM as it's known) in the Federal space for a while. The U.S. Fed Gov has been implementing MFA with smart cards since 2001. While there are pockets of ineptitude and resistance, the vast majority of government employees and contractors use a hard token second factor. Security is a property of a system, so analyzing a particular password policy outside of th…
Yes, and the latest Zero-Trust guidance is actually legitimately good - it enforces a security practice on all gov agencies that will be better than 99% of the private sector. The password policy is just one line, but still a welcomed slap on the face of all Old Guard folks (who are overrepresented in infosec policy-making). The rule is clear: MFA or GTFO.
I feel like this post was intended to inflame or shock the reader with the writers stance on password policy. But anyone who has been in security for more than 1 month knows that regular password rotation has not been a recommendation for over 5 years. Both NIST, and MS have been trying to get the world to move to long, never rotated password, so long as those passwords are dictionary checked. Every company (all 3 of…
Both password rotation and special char requirements (which often interferes with strong password generations because other systems don't support same character sets) are very much alive and well in govt contracting / vendor requirement land. Ie, they are still very very common. In a business when the password reset request rate gets high, it usually gets easier and easier to reset passwords. I worked with a govt sys…
Earlier quoted context omitted.
Automated password rotation would use machine generated highly secure passwords. I do not see your point. This issue for master passwords is a bit harder, yes.
If you're using machine-generated passwords, then what's the point of rotating them?
Earlier quoted context omitted.
Working at a acquisition of a big consulting corporation. Had these recommendations in place before being acquired. We're onboarded onto better security systems by new mothership. Password rotation every 75 days. No dictionary check. No check against known breached passwords. No real reasonable rules against insecure passwords (like ac_Paul2022 is valid 'secure' password). Additional massive "spyware" on corporate de…
Why should a corporation design its information controls for users who "care" about infosec, rather than designing for the overwhelming amount of users who don't care at best , and at worst are insider threats?
I needed to have less secure passwords under new security regime. More open ports. More services being exposed to the net, more code with potential bugs running on my machine and so on.
If you want to take over any of the big firms I would probably target a tool like Tanium [0] being employed by a lot of these corporations.
Last time I checked still based on python 2.7 (EOL 2020-01-01).
This was in my case installed as well as Flash with the pretense of security. I was a bit underwhelmed.
I actually told CIO about py27. And about it already being EOL. They did not know that (neither the tool using it, nor it being EOL). And they actually did not care. And told me not to care about it, as the mix of different tools would provide absolut security.
There is no need for passwords. Cant we figure out something better? its only been like 50 years.
I am very curious why public private key auth is not a thing for websites and applications. I would rather have a single password to the server that publicly hosts my public key then I can simply point websites and applications to that address during signup. Every app/site would check the server every 5-20 mins for changes to my public key in case I need to change it. Then I can use my private key to authenticate to…
Now, public key cryptography is indeed promising, but you see something rather more sophisticated to deliver privacy and security and that's what WebAuthn is.
Earlier quoted context omitted.
A business card stored in a wallet or purse is pretty good too. After all, we're already pretty used to protecting our credit cards, identity cards, and cash.
It's pretty bad to put both a debit card and it's password together. The only reason it's even tolerable risk to walk around out in the wide random world with a debit or credit card on your person all day every day, is because somewhere else you have the means to disable it and declare it lost. This is like storing the keys to your car conveniently right on your car.
There is no need for passwords. Cant we figure out something better? its only been like 50 years.
This does exist: Passwordless with FIDO2/WebAuthn has been gaining some decent traction.
I have no idea why this wasn't immediately huge. You see the login button, you tap it, your existing fingerprint reader or whatever verifies you are still you, whoever that is, and you're logged in, done. Much more secure than people's crappy passwords, yet much easier to use even than the crappy passwords.