Prohashing Mining Pool Forums

This weekend, I'm going to set aside ten hours to resolve issues with the website and mining server, and ten hours to add new features for security improvements. SHA-256 mining will be delayed by the security improvements.

My primary goal for this weekend is to implement the best way to deal with password resets. With the help of users in the forums, before tomorrow night I want to come up with a way that is easier for the customer, more secure, and which continues to reduce customer support requests from Chris.

The current password reset procedure is for users to E-Mail Chris with a signed message, or to send Chris money, from an address associated with the account. This method is no longer workable because it costs almost $8 for a proof transaction if done with bitcoins. Additionally, we've found that criminals are targeting customers who reuse passwords. Theoretically, they could change their payout addresses, after which they can sign a message from the changed payout address to defeat the system and get a password reset.

I've come up with a few ideas, and hope that others will come up with more so that we can choose one to implement before tomorrow night.

• We could simply change the policy to state that no password resets will ever be accepted, and people who lose access to their passwords will receive payouts when accounts are purged after 90 days. This may turn out to be the best policy. The major downside, of course, is the loss of statistics in these accounts which would be permanently inactive, and anger from customers who won't be helped. The upside is that there is no personally identifiable information required to enforce this policy, and little or no money is lost because the payouts would just go to the addresses in the lost account.
• We could enable users to enter their E-Mail addresses, where password reset messages can be sent. When requested, the user clicks on a link to reset the password from an E-Mail. I think this method actually reduces security by adding a vulnerability of securing access to an E-Mail account.
• We could create a policy where the user has to identify something unique about the account to get a password reset that is not available to the public, like the names of all the workers which have connected to the account in the past day. Other private statistics, like electricity cost, could also be used. We could even automate the signed message process in this way if it is determined that is secure enough.

Of the three, I think that the third may be the most secure and easiest for everyone. The process can be automated through an online form, and then any manual requests to Chris can simply be rejected.

We could also combine the third with an optional E-Mail notification, so that if a reset occurs, the account owner gets an E-Mail. I suspect, however, that most people would not enter their E-Mail addresses, and therefore would not take advantage of these E-Mails.

Please offer your thoughts on how we can improve the password reset procedure so that I can implement the changes this weekend.

Can't you enable 2FA (2 factor authentication) - perhaps using the Google Authenticator.

Then go with Option 2 and allow the user to request and complete their own PW resets - the added security of 2FA would mitigate the decreased security of PW resets via email. (or any other "self service" method you may implement)

For a good usage case in action, pop over to HashFlare and setup an account, and enable 2FA with Google Authenticator providing the codes.

For some alternatives to Google Authenticator have a look at this article - https://themerkle.com/top-6-secure-alte ... enticator/

You can of course make 2FA "highly recommended" but optional - with clearly stated warnings and policy for not enabling 2FA (a sort of disclaimer of any responsibility if user account is hacked and no 2FA has been enabled)

I like the concept you are currently using of doing the signed messages because if someone has been hacked by using common passwords it is logical to assume other accounts (email) might have been hacked. A signed messages proves ownership over the wallet and this could be something automated and very secure and also providing no personal identifiable info.

You would need something like.

"Please send an encrypted message containing just the string 'prohashing.com' to resetmypw@prohashing.com to prove ownership" Your password will be reset to your wan ip address for 30 minutes.

This way we provide no web interface even to be manipulated, only the email system need hardening and there are plenty of mature solutions for this.

Tmopar

Also, for this purpose to make the system simple we can say that everyone has to have an LTC wallet... this is free and i dont think signed messages require a balance. It might also help promote LTC slightly in payouts.

Otherwise we could design this as a wrapper specifying a wallet type for ultimate implementation but having a generic IO call for any wallet type.

we're all pushing for 2FA id dosnt require alot of changes on your end and forget google auth authy has the whole api to built it into your website. its much more secure that way.

Now that lunch has arrived, I can reply to this with my thoughts.

First, I think I need to clarify that 2-factor authentication and this issue are separate topics. There will still be password resets even if two-factor authentication is used. In fact, there will also be "cell resets" requested too. Plus, two-factor authentication isn't a solution for password resets, because if you are allowed to use the cell to reset the password, then it becomes "1-factor" again, which is just as secure as the password is.

I'm not sure there is any way to provide for password resets, and the reason is that if a user's account is hacked, the hacker will undoubtedly change the payout address as the first action, so the owner won't be able to sign a message with the new address. We can't protect against this with E-Mail notifications, because the hacker will just change the notification address first.

Perhaps the best solution is simply to change the policy to no password resets under any circumstances, and anyone who loses access to an account will have the balances paid out after the 90-day deactivation window. Then, two factor authentication can be made optional for users who want additional security.

No Steve, the 2 are connected. Even if the hacker manages to change the password, when he tries to login he will not have the ability to generate the code that will be requested. Think about it

With the second layer of authentication you mitigate the risk of "self service" password resets and can implement this solution to reduce the service requirements on yourself and Chris.

2FA with an "authenticator" service providing the second layer of security is how many of the big sites are setup, and they allow for use self service password resets, knowing (as I said earlier) that a hacker who somehow manages to change the password, will still be foiled when 2FA demands a code from a device/service that they do not have.

even on password change requests 2FA code is required. its not just for login it can be set for any account changes including payout threshold or payout address if you wish to allow that as a user customizable option
\

even on password change requests 2FA code is required. its not just for login it can be set for any account changes including payout threshold or payout address if you wish to allow that as a user customizable option

Exactly.

2factor also exposes a lot of personal information in the process... whereas if we can keep it witihin the cryptocurrency facility itself we retain as much of the anonymity we started with.

How about we lock the payout addresses period and they cannot be changed unless they send an email to unlockmybalances@prohashing with in the subject the coinname exactly as it is the block explorer and in the body the encrypted message "Release my account".

This way only someone who has control over the wallet (and not email or prohashing's website) can make any meaningful changes!