"Well, Per isn't exactly a rocket scientist, and I have to help him with anything from shoelaces to toilet visits, but he is a KEEN debater in Internet forums..." |
It's a simple idea really:
- Would organizations relax their written password policies after implementing 2-factor authentication?
- Would users (humans) relax on their own password length/complexity because of 2-factor authentication getting implemented in the organization?
- Would the PIN/password part of any 2-factor solution be implemented and aligned with any existing written password policy, or would the additional factor introduction also introduce a revised/new password policy?
Background
Long time ago, in a galaxy far away, I made observations before & during the implementation of RSA SecurID in an organization. After some time in production I also got a chance to do some audits, and quickly discovered admins and select leaders from top management that only used their static 4-digit PIN to log on. They had simply disabled the OTP part "because it was so cumbersome to bring along the SecurID token all the time." You can't fire people in Norway because of such answers.
Their external auditor asked the question "Do you have a 2-factor authentication solution in place, as required by XYZ?". The answer was "Yes", and everything was fine (to the auditor with the checkbox form). Then I joined the party :-D
From this I once again confirmed the importance of formulating my questions as an auditor correctly. :-)
APT happened to RSA
...and the world of cyber security apparently changed. I didn't really think much of it before that incident, but after they got pwnd I thought to myself "Why can you only use 4-8 digits with your SecurID token? How are those digits stored in the authentication server? What if that server gets compromised? Damnit, I want UTF-8 support!". Afaik RSA now supports using mixalphanumericals (specials?) along with your OTP & system password. An improvement I would say, introduced after the APT attack. (I'll stop writing APT APT APT now).
And here we are.
And here we are.
The basic question is..
Will the introduction of a 2F solution weaken the 1 factor we know - your password, because you put your trust in the second factor, which will usually be something you have?
My problem is..
I don't trust technology to fix anything, unless we do it right. Go on, try to figure out the root problem in that previous sentence.
What I would like to do
I would like to crack the passwords of all employees / accounts in a Windows Active Directory Domain before a 2F solution gets deployed to the organization, as well as preserve the current written and technical implementation of the password policy (Those usually is a solid gap between those two).
There we have our base level.
Then after 6-12 months I'd like to see the written password policy, the technical implementation of it in Windows AD, and the policy implementation in the 2F solution. Last but not least, the "this is always depressing" part; crack all the passwords in AD, and with proper support (hello @hashcat @solardiz), crack user-selected (?) PIN/passwords that eventually go along with the OTP from the 2F authentication server.
I have this itchy feeling feeling the results would be interesting, in the sense of IF admins disable the second factor (something you have), or APT (Oops... Sorry!) happens again, we'll find ourselves in a situation where the oldie but goodie factor of something you know suddenly is the only factor keeping APT at bay. (woohoo, I'm creative today!)
HOW/WHERE/WHEN/TO?
No idea. Any volunteers? I'll happily join in, but currently I don't do security audits or password cracking on a regular paid basis, so it is a bit difficult to this by myself right now. All proposals welcome. :-)
No comments:
Post a Comment
All comments will be moderated, primarily for spam. You are welcome to disagree with my posts of course.