r3@lg00dp@$$w0rd
Obviously a bad password, it has a repeated character, and doesn't have capitals
New password strength requirements coming in 3...2...1
Welcome back to PWNED, the weekly column where we warn you about weak security practices. This week’s terrifying tale involves a lack of important patching and a humorously bad password belonging to the person in charge of tech security at a law firm. Have a story about someone leaving a gaping hole in their network? Share it …
I can neither confirm not deny that we have a Windows shared build system account with a password that now ends in 40
And an outlook reminder to change it every 89 days
And every 90 days we think we should look for a way of scripting the password change if you don't have any sort of admin privilege
Last time I updated my password in that fashion, the system complained that my new password was "too similar to the old password".
Why the fsck does it know what my old password was, or care about similarity? It needs to know is whether the hashes match, and nothing else - otherwise, we have vulnerabilities like this one. I'm talking about a system where I need to sit down and pull a password out of my in-head memory multiple times a day and all it seems to be tolerating is random strings of letters, numbers and symbols, which apparently I have to change every 30 days despite 2FA.
I can't know whether this specific system did it the normal way, but many systems check the new password against the old password for similarity. How do they manage this task without storing the old password in plain text? Easily, because before they let you specify a new password, they make you enter the old password first, and they keep that old string only for the session. That is not a sufficient indication that they kept your password insecurely the rest of the time.
"So what can we learn from this tale of legal embarrassment? "
We can learn that the legal profession are nowhere near as bright / skilled as they would like to think they are.
.. any of us who have had much in the way of dealings with them are aware their only obvious skill is stringing out minor administrative "paperwork" tasks as long as possible whilst also including as much chargeable time as possible in that process.
In the Windows System, for about 20 years now, there is a easy way to store passwords secure. Can only be decoded on that machine and that account it is bound to. The API has been there even longer, but for about 20 years easily accessible via powershell (possibly before, others may know better than me).
There is no reason for cleartext PW, not only as "storage", but for scripting as well.
(Of course the PW is, at some time, accessible since it has to be decoded to use, but unless you force exposure by writing is in clear text in a log file or something similar stupid, is not visible outside your script context)
Oh while we are at it: The arzue/entra authentication, for "service account" which cannot use 2FA, does transfer the password IN CLEARTEXT as https post request. Yes, the HTTPS is there, but before the password was not transferred as cleartext but as hash over LAN cable for 25+ years now? Even in the MS world?
Unless you're using some form of Public/Private keypair, you either need to store the password or transmit it.
For example the old MSN protocol had the server send you a string, you stuck your password onto the end of it, hashed that and returned that. They could only verify that because they stored your password.
The current process makes the trade off that it's easier to secure the one-off transport mechanism instead of storing the password.
You never need to store the password in a reversible or even cleartext way on the server side. And transmitting over the line is not cleartext as well. Not even Windows NT 3 with NTLMv1 server did that. The weakness of NTLMv1 is the used hash method. Later the transmission got encrypted too, secure Kerberos / LDAPS came too. The last two mentioned, somewhere 25 years old now in the Microsoft world, not only used encrypted transmission (optional, much too late enforced), but never transmitted the PW within the encrypted channel in clear text.
Entra / Azure, for example AppId authentication, does only secure the communication, but the PW is transmitted cleartext. They COULD have done it better, and even with Powershell a challenge response if not that difficult to set up. DOTNET 4.* (which is Powershell 5.1 level, though you SHOULD have the latest DOTNET 4.x) has everything needed. I still feel weird when I implemented that for first time THIS YEAR, 'cause the on-prem-exchange got disposed, and this is the newer "better" method to send mails.
> The current process makes the trade off that it's easier to secure the one-off transport mechanism instead of storing the password.
No, they are just f-up lazy bastard who don't give a shit about security at the design level of such things. MS was better. (well, not all MS employees are, but too many of those are there somehow)
For work I need to have a normal password and an admin password. I enter he normal password once every day or two and the admin password about 30-150 times a day depending on which systems I am jumping on and off to do work.
Needless to say they have different rules for password complexity and the one I use more often is the longer password.
Fortunately we only have to change them once a year, the downside is for a couple of weeks I spend time sitting waiting for the hold flag to time out after getting it wrong…
What are you, 16?
But then, "doing cyber security" on windows does require a certain... immaturity. So it doesn't really surprise that most of the "cyber" people started young and, while growing older, never really grew up. Horses for courses and all that. Wading around in windows shit is a target-rich environment for pointing fingers and going "ha ha, he's got shit all over him!!11!1!!" Like you don't. But it's a meal ticket. A shitty one, but a meal ticket.
I never (well very. very, rarely) downvote, so it wasn’t me, but I have read this post through four times now but am really struggling to get your point.
The closest I can come is that you are suggesting that Windows is so full of vulnerabilities that it’s low-hanging fruit for pen testers, and only low-skilled people get involved. But on the other hand, lime it or not Windows is the dominant OS in business, so.....?
Sorry to say, but you have come across as a bit of a twat. But as you have posted as AC, we’ll never know.
Our company once had an internal townhall meeting on Teams, a section of which was on cybersecurity.
Unfortunately the person giving that part of the talk had his whiteboard behind him on full display... and which had login details for at least 3 different accounts in full view. But hey, at least there were only around 200 people viewing at that point in time...
Yes possibly a honeypot, but "an internal townhall meeting on Teams”, so if it were then who were they trying to catch?
I’m inclined to agree with you that this was deliberate to see if anyone noticed and commented on it. On the other hand I have seen some jaw-dropping displays of complete incompetence by some companies, so maybe?
Hmmm,
Having worked within an organization that was ACTUALLY concerned with information protection... we did a fair bit of research into (yes sorry..largely American) government published security guidelines.
The NIST org in the US updated SP 800-63 in 2016 with wording that recommended the elimination of 'Strong' passwords. Such passwords typically caused some of the security faux pas as documented in other comments...re the Whiteboard info on Zoom!!
Know thy attack surface: in any reasonably secure system (non Cleartext passwords!) the password hashes were more likely to be attacked...not the human readable password.
One should also be aware of the significant diffs between the cipher/hashes used for passwords vs..say an HTTPS session...where the former is slow and ponderous (in computing resources) vs. quicker and responsive (Gawd forbid if you have to have to comply to FIPS 140-n or such obsolescent standards!) . Thus the real key to improving password security was to ensure that finding a string that once hashed matched the stored hash (using a hash such as ...say bcrypt or something new/better) was an expensive operation. Thus the LENGTH and ONLY the Length of the password truly matters. Be gone with upper/lower/numeric/special character requirements!!!!
Now, having gone on as I have, I have not been in close touch with Cyber/Info Protection since late 2018...so if someone wishes to challenge me on the above - please do, I will such ingest as much Canadian Prairie Crow as necessary -- but be damned...NOT a complex password!!!
where he found that the passwords were stored in plain text and easy to dump into a file, no decryption necessary.
why where the passwords collated in a file?
is this how windows does its authentication? querying the password against an unencrypted list of usernames & passwords
rather than complaining about teh choice of password, they pentest should be making it clear there are better ways to store passwords.
Embarrassing the ciso like that is 1 way to get the point across, not sure many commentators here realised that the unencrypted list of passwords was the main issue here aside from patching to latest patches.