PM ordered me to not use encryption for customer authentication links because we want to be able so send same link if the user loose it. "we have to prioritize usability over security". At least I can tell future hackers it's not my fault..

I don't understand, if you just used remember_token like it uses, why can't you send the same link to the customer. Unless of course you are explicitly expiring the tokens.

Even if you expire the tokens explicitly, they can be refreshed and the link can be sent to the user. Why would he have a problem with that.

Also, even remember_tokens are not encrypted, they use str_random(100)

The token in this case is the password which will be sent in an URL to the user, then they click the URL to login. If the user looses the link we can send it again, and instead of generating a new password we apparently need to send the exact same URL. Because it would confuse the user to get a new URL even if they lost the old one..?

Guess I fucked up extremely trying to flame my PM with a bad name in my db, now this is a flame op thread

My laravel loving heart is breaking

And everyone getting access to that URL gains access to the system... You know it is stored in the browser logs? If hes going through a proxy it stores the url as well?

@Hakash yes I know. Doing like this makes the customer area public property... I don't want to have this blood on my hands 😕

@tobbeboi Wow... And you have to work with this PM on all projects?

I guess its not all his fault. Forgive me for saying this, but this is what it appears to be.
If you ever want to include this project in your portfolio, better clean up the mess. Rebel against the PM if possible, escalate the issue. What's the use of such a project, unless of course you are heavily dependent on it finance-wise.
That's what I feel.

You'll have to educate your PM then. Otherwise, next thing, he'll blame you for the security hole