Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
it's good practice to enforce a password renewal every 3 months? 🥺
With enstated password quality requirements.
Even better would it be if they're using Google G Suite. With the Google Identity Platform it ensures seamless and secure login and admin of acess rights. Google Identity Platform can be connected to to the Active Directory which ensures security on Hardware Level. Heck, If the employees using the Chrome Browser they don't even have to enter the password thanks to the single sign in WebAuthn API.
Google Identity Platform
https://developers.google.com/ident...
WebAuthn
https://developers.google.com/web/... -
-
@devTea i was about to say something like that. At one point the user needs to be accountable for security best practices
-
:facepalm:
On the back-office I built for my last employer I had to take some some action to keep this kind of crap under control:
- 90 day mandatory password renewal, can't reuse passwords for 1 year
- 2FA mandatory for everyone
- zxcvbn on the password change page to give them some hints
- and I may have leveraged zxcvbn to actually prevent users from setting passwords that were too simple -
I read somewhere that password complexity rules are crap. This particular article suggested just one rule: min length of something like 30 or 50. Passwords in that scenario should be phrases. They are easy to remember, and long enough to be essentially unassailable via brute force. Ex. "I don't care if password is in my password, so suck it."
-
@JohanO Exactly!
-
@dudeking that only helps in the context of storing passwords - and even then, salts are stored along with the hashed pw, so if your password is "password" you bet your ass I'm gonna try it.
If I'm doing a bruteforce login attempt on your admin console though, no amount of salting and encryption in the backend is gonna change the fact that I'm getting in when I correctly guess your insecure password
The situation right now:
Our client: full of legacy desktop solutions that always ran inside a VPN, but wanting to modernize the system and migrate to be hosted in the cloud.
Our first project with them: Frontend built with Angular, backend in a serverless model, all with GraphQL and heavily tested to assure quality. The system is mostly an internal software for management, but the backed may receive data from an App.
The problem: all management users have weak passwords (like "12345", "password", or their first name).
The solution: restrict our system to be accessible only inside the VPN
The new problem: how the mobile app will send data to our backend?
The new solution: Let's duplicate the backend, one public and the other private. The public one will accept only a few GraphQL operations.
------
This could be avoided if the passwords weren't so easily deductible
rant