0

I've multiple applications running in sub-domains, under a parent-domain that I have no control of. They all require a login, which works by sending to an API request that I also have no control of.

The downside of this is that they all require login if you jump from one to another. A solution for a "single sign on" is to make a portal site that require a login once, where you then can access all these applications from there. Still, you can't jump from one to another without login, but at least you can do so by the portal-site.

The idea:

1) Encrypt your id and password upon login that will be stored in cookie in the portal-site.

2) Once visiting other page, the encrypted id + password will be sent over to the url, and then in the visited application, send the encrypted value to the backend (via my own created API) to be decrypted..

3) Once decrypted in the backend, an API request will be called for login (instead doing it on front-end as they currently does).

In other word, I will create a backend server, making a new API request to recieve the encrypted value, decrypt, and then use the actuall API request for login (that I have no control of).

Does this work, or is this againt GDPR? Is this far fetched, is there a better method?

( I'm not very experienced with this area )

Raithar
  • 13
  • 4

1 Answers1

1

Well first, this is not the main issue GDPR would actually look into (if ever they do). It mostly deals with how you handle the user's data, what you do with it, and how much power the user has over its data. Of course, this s not exhaustive and a lot of things must be taken into account.

However, as for your question:

First, NEVER store a password in cookies. I mean, never store a password. Never! Even encrypted. But you can use them so that a token for authentication is generated. More information about that here

Secondly, use HTTPS. Why? Well you should send your credential through a TLS

Finally, encrypting the password on the client-side is pointless for some because of TLS, but I find it eventually more secure as long as it can't be easily reversed (see client-side encryption). Another question that would answer partially yours. However, it is pointless to decrypt a password on the server-side. It would even decrease the security of your process. In fact, you should encrypt it on the server-side with a strong one-way hash function, that will be stored in your database, and use as a comparison element when the user tries to log again. Every time he wants to log-in, the password sent to the server will be hashed, and this hash will be compared to the one stored. If they match, the authentication is granted. If not, the user is refused access. Therefore, the actual password is never stored.

You can also look into OWASP which is a great resource for Web Application Security.

R4zZ
  • 26
  • 3