Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
389 views
in Technique[技术] by (71.8m points)

node.js - Client-side encryption in NodeJS/Javascript

I am working on a project where I would receive some personal information from the users (most importantly, phone number). I have been researching on both client-side encryption and server-side encryption, yet am unable to make a decision on which is more suitable.

Currently, the database table includes two columns: column 1 that stores the encrypted phone number (using asymmetric RSA encryption), and column 2 that stores the hashed value of the last four digits.

The reason why I am trying to do this is because: 1) I am trying to create an admin page where I can view the phone numbers (therefore I can't just hash the phone numbers) and 2) the user will use the last four digits of their phone number to verify (thus, it would be very complicated to compare the last four digits to the encrypted full phone number).

This is the code I used to implement asymmetric RSA encryption. Based on my understanding, such encryption is considered server-side encryption. If I want to use client-side encryption, how should I go about implementing it? Please help!

enter image description here

question from:https://stackoverflow.com/questions/66060388/client-side-encryption-in-nodejs-javascript

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

Assuming you're using https to transmit the data from client to server (which is required for any level of security) and thus you will be transmitting the whole phone number anyway (because you want to store the phone number in a retrievable way), there is no real point to doing client-side encryption or hashing of anything. Just send the phone number from client to server under the protection of https. And, if you find a particularly good reason for storing a hash of the last four digits, you can compute that hash on the server from the whole phone number before storing in the database.

And, if you're not using https, then please don't try to reinvent your own public key/private key encryption to try to get some of the benefits of https while still using http. Just use https and stand on the shoulders of 30+ years of development that have gone into that along with all the other benefits it provides.

Any client-side symmetric encryption requires the key be present on the client which is a horribly massive security risk since any client suddenly has access to your key which basically renders the client-side encryption pointless. This is the whole reason that public key encryption was invented and is used by https. So, just let https do it's job to protect the data in transport between client and server.

Your could do public/private key encryption where your server has a private key and you give the client the public key and it uses that to encrypt the data, but it is not really clear what benefit you are getting from that because the data should already be protected in transmit by public key/private key encryption via https.

Once, the data is on the server and you want to store it in your database, it is a separate discussion about whether you want to encrypt it in the database using a server-stored and secured symmetric key. Sometimes that is a good idea and sometimes the circumstances are such that doing so doesn't really increase your level of security for a variety of reasons (mostly around how the key itself isn't more secure than the database).

I don't know of any reason why you would use public key/private key encryption all on the server. That's a bunch of extra computation for no real benefit if everything is stored on the server. The big reason for using public key/private key encryption is so that you can give out the public key to anyone who wants to send you encrypted data, but that public key can't be used to decrypt the data that was encrypted with it. For that, one would have to have the private key. For data that is kept entirely on the server and managed by the server, you already would have to secure the private key so you may as well just use a symmetric key and secure it. There is no "third party" that you're asking to encrypt data without having the ability to decrypt the data which is the main reason for public key/private key encryption.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...