PenguinCoder

@ Penguincoder @beehaw.org

Posts

71
Comments

578
Joined

4 yr. ago

Bit-breaker working in cybersecurity/IT. Only languages I know are English and Programming ones.
Sometimes I write things about technology.
`If I told you the SHA256 for this sentence starts with 'c, 5, four, a, and a', would you believe me?`

Moderating

Beehaw Support beehaw.org

Lua programming language sopuli.xyz

2mo ago

LexisNexis confirms data breach as hackers leak stolen files
Jump
PenguinCoder @beehaw.org 2mo ago
For 70% of the companies out there, If your company or website collects it; hackers will get it. Your PR 'trust us' words have no meaning or substance.

2mo ago

I get along with every coworker but 2 out of 14, manager is somebody who sabotaged me in the past. To even consider working there again is such a stupid idea, isn’t it?

Jump

PenguinCoder @beehaw.org 2mo ago

People don't generally quit bad jobs, they stick it out for whatever reason. They do quit having a bad boss though.

There's a really nice high level overview of TOP/MFA by OWASP

They say:

There is no definitive "best way" to do this, and what is appropriate will vary hugely based on the security of the application, and also the level of control over the users. Solutions that work for a corporate application where all the staff know each other are unlikely to be feasible for a publicly available application with thousands of users all over the world. Every recovery method has its own advantages and disadvantages, and these need to be evaluated in the context of the application.
Some suggestions of possible methods include:
Providing the user with a number of single-use recovery codes when they first setup MFA.
Requiring the user to setup multiple types of MFA (such as a digital certificate, OTP core and phone number for SMS), so that they are unlikely to lose access to all of them at once.
Mailing a one-use recovery code (or new hardware token) to the user's registered address.
Requiring the user contact the support team and having a rigorous process in place to verify their identity.
Requiring another trusted user to vouch for them.

The most important thing I think is, the MFA reset should have a different method and flow than the password reset option. Figure if an attacker attempts the 'forgot password' method, it's assumed they have access to the users email. Therefore, you don't want to send a 'reset MFA' in the same manner. The password recovery flow should be separate to the MFA recovery flow by using some form of out-of-band verification such as sending a password reset link within a "forgotten password email" containing a randomly generated and unique token that allows the user to reset the password only. The MFA recovery flow should work in a different manner. If you are offering TOTP only, I suggest offering a fallback method in place such as a list of "backup codes" of valid OTPs that the user needs to keep safe, and is obtained when first enrolling in MFA, or otherwise an OTP sent via SMS with a short expiration time. Ask for the TOTP while entering a new password. The reset link would be useless for the attacker.