Loss of password of the private key after registration.

[descampsk]

Hello !

Currently if a user loses his or her Ethereum account password after registering, he / she is no longer able to vote and the vote must start from scratch.

I would like to know if you had already thought about a way to allow the loss of a user's password.

I was wondering if a mapping between the old key and the new key could be enough.

Let me explain :

The administrator entered the "0x56" key of a voter A. However, voter A lost the password to access his account. He goes to the administrator, proves his identity and that he is the owner of the "0x56" account. And that he created a new account "0x25" The administrator sends a transaction to the Voting SmartContrat to map the "0x25" account to the "0x56" account. Thus, for each transaction from "0x25", the contract will look if this address is linked to a registered address. If this is the case, then it will authorize the vote from that address as if it originated from the old address. Of course, a check must be made to prevent an old address from being linked to two new addresses.

What do you think of this system?

Thank you :)

[stonecoldpat]

Hey.

I get what you mean - the password to unlock the Ethereum account. I hadn't considered that.

A new function can be added to allow the Election Admin to 'un-register" a voter. So if the voter cannot log into the vote.html (i.e. lost password) - the election admin can un-register their previous address, and register a new address. If the voter hasn't registered for the election (i.e. left a deposit) - then this should be ok. livefeed.html could be updated to reflect that a the identity has been replaced,

A problem arises if the voter has registered for the election, but then forgets their password. If this happens DURING the registration phase - a new function can be added to let the Election Administer move the deposit from address A to address B, and cancel the registered voting key from address A. However - this introduces a new problem - the Election Admin can use this function to steal a voter's deposit - so this needs to be kept in mind if pursuing this approach.

If the voter forgets their password and we are in the VOTING stage... then the election needs to be cancelled, and each voter must re-register for the election. This is because the voting keys need to be fresh for each new election.

---

Since you are using a docker image - perhaps it might be possible to cheat a bit like I did during the testing. I hard-coded a password in the vote.html and all accounts used the same password. The Geth node in the docker image could also be set up to use the same password to unlock the ethereum accounts. Of course - if this approach is followed - then the voter should know not to use the docker image as their primary wallet... but it might help with early deployment / user-testing.

[descampsk]

Thanks for your answer.

I think I won't use the deposit function. At least, at the beginning.

I do not fully understand why the election should be canceled if a voter forgets his or her password during the voting phase.

To vote, the voter only needs his voting key that he has stored locally and is independent of his Ethereum account.

Why not create a mapping between the old address lost and the new address created (mapping (address => address) public addressLost)? And when verifying the vote (if (registered [msg.sender] &&! Votecast [msg.sender])), we look at whether the address is in addressLost. If so, then we check if the linked address is registered and has not already voted. If not, we check if this address is registered and has not already voted.

This will give in pseudo-code:

if (addressLost.has(msg.sender)): addr = addressLost[msg.sender] else: addr = msg.sender if (registered [addr] &&! Votecast [addr])) : VOTE....

Is this possible ?

[stonecoldpat]

I do not fully understand why the election should be canceled if a voter forgets his or her password during the voting phase.

The zero knowledge proof checks two things:

1. The proof was created from their voting key.
2. It was sent by the user's registered identity.

If the user cannot log into their identity (i.e. unlock private key) - then the zero knowledge proof can't be created.

To resolve the problem - I think the addressLost idea looks nice. I can't see anything immediately wrong with that approach. You need to trust the election administrator to do that though - but that would be publicly detectable anyway. I'd suggest updating the livefeed.html to show that is what is happening! I'll chat with my colleagues about that though - I hadn't considered it.