delete the WebCall user ID

[NCHU611A]

Is there a function to delete the WebCall user ID?
Thank you.

[mehrvarz]

WebCall ID's outdate automatically when not being used for a specified duration (6 month). Why delete them explicitly? To make them available for re-use by another party?

[nscomputing]

We do not store any personal data (real name, email address, etc.) anywhere.

In my opinion, the personal password (a part of personal data) should be encrypted on the server side. A server administrator must not be in position to compromise account integrity and be able to impersonate an account holder.

Proposals welcome:
httpLogin.go // here we could encrypt the pw
httpServer.go // here we could decrypt the pw

Please implement saving encrypted password to required database files on the WebCall server.

My proposal:

1. There is no need to decrypt the pw.
2. Encrypt the password by registration of WebCall ID and save it to required database file(s).
3. Encrypt the password entered by login and compare it to the encrypted password in database file.

Thank you.

[mehrvarz]

A server administrator must not be in position to compromise account integrity and be able to impersonate an account holder.

Administrators will always be in a position to compromise account integrity. How long do you think would it take an ill-minded admin to compromise the most advanced pw-encryption measure? 5 minutes? I can think of no true solution to this. And I am not going to participate in security theater.

But why don't you contribute an actual solution we can look at? Or maybe someone else? I am abs willing to integrate any sufficient solution.

One goal of mine is to not ever show, print or log any user passwords in any situation. So that well-meaning operators do not unintentionally get in touch with them. I personally have not seen a single password in the clear just once since I started this project. (To casually point this out.)

[nscomputing]

But why don't you contribute an actual solution we can look at? Or maybe someone else? I am abs willing to integrate any sufficient solution.

Unfortunately, personally I am not a Golang developer.

[mehrvarz]

My proposal:

1. There is no need to decrypt the pw.
2. Encrypt the password by registration of WebCall ID and save it to required database file(s).
3. Encrypt the password entered by login and compare it to the encrypted password in database file.

This has been implemented now with some guidence from: https://medium.com/@jcox250/password-hash-salt-using-golang-b041dc94cb72
The new implementation is already online and active for new accounts being registered. If you set up a new server, all passwords will be stored in an encrypted format. I am thinking about converting existing (live) accounts. But there are some operational risks involved with that.

[mehrvarz]

Created (one-off) code to encrypt all remaining passwords. Ran this code today without a single clients noticing. Now there are zero unencrypted passwords left in the WebCall db. Voilà.

[NCHU611A]

WebCall ID's outdate automatically when not being used for a specified duration (6 month).

Got it.

Why delete them explicitly? To make them available for re-use by another party?

I thought that if new IDs are registered all the time, but there is no deletion mechanism, will it cause insufficient memory or insufficient IDs?

Thank you!

[mehrvarz]

will it cause insufficient memory or insufficient IDs?

Registered callees are kept on disk, not in memory. Callees use up very little disk space, so you really don't have to think about it much. And once you run the service for more than 6 month, old/unused callee entries will get discarted automatically in the background. So from that moment forward the db will only grow if you see more new callee users than old/unused accounts being removed.

The ID range allows every human on earth to have 10 ID's per server. Or if 'only' 1 in 10 humans use the service, they can each have 100 ID's, etc. There are two actual limiting factors: 1. number of concurrent/online callees (roughly 30K per GB RAM); 2. concurrent call-requests (roughly 300 per min per intel/amd-core, or up to 440K per 24h per core, probably more). I think an "Advanced server topics" page may be needed, like the one that exists already for the Android client.

[NCHU611A]

Got it.
Thank you!