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

  • 13
    OR, don't do any of that and let them burn in their own stupidity. Sometimes it's the only way to drive home a lesson.
  • 7
    O.d.d.a.o.t* and add a client certificate besides user/pass

    * = Or dont do any of that
  • 14
    @dudeking you can salt and hash all you want - you're still gonna get pwned if your password is literally "password". Hence my preference for natural selection
  • 3
    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

  • 10

    Old: Password123
    New: password123

    This is true story from our management btw
  • 3
    @devTea i was about to say something like that. At one point the user needs to be accountable for security best practices
  • 5

    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
  • 3
    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."
  • 5
  • 1
  • 2
    Have you looked at Webauthn? I am currently in the process of building an implementation.

    Could go passwordless altogether.
  • 1
    @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
Add Comment