Jump to content
Twarden

The Troubles of Single Delivery for Ripple Account Activation

Recommended Posts

Single delivery of a funded ripple account to each unique person poses some interesting challenges to overcome should a service provider wish to provide such functionality.  Should a service provider wish to provide users with a new account who are completely ignorant of Ripple or cryptocurrency altogether, some troubles arise when attempting to create a system which provides new users with a funded ripple account in such a fashion that only one account can be provided per individual.  The issue with creating an automated system such as this is that it will be abused by people who create their own automated systems in an attempt to steal all available XRP allotted to the service provider's account which would activate new accounts.  

My question is what is the best available methods of identifying an tying an identity to a device and/or user's network access point to ensure an activation system such as described would not be able to be exploited through automated attempts to steal XRP?  I surmise you can't use cookies, local storage, cached data, session data, or checking repeat IP address  claims to block new accounts from registration, so what methods remain?

Edited by Twarden

Share this post


Link to post
Share on other sites

In this scenario, I assume we are playing the role of a gateway, correct? 

So, if that's the case, then the gateway will fund each wallet with a small, minimum amount of xrp.  Were I the gateway, I would have an overall account for an individual, that must be funded prior to my creation of their pre-funded Ripple wallet.  Basically, I am then covering my out-of-pocket cost of pre-funding their wallet.

Or are you thinking of creating an automated service that will open an API up and prefund wallets with a minimum of XRP to try to get increased adoption of XRP?  In that case, abuse is far more difficult to curtail.

Share this post


Link to post
Share on other sites

It's really hard to anser this question. You don't provide any sort of guidelines about what rates of type I and type II errors are acceptable, or any limits on the platform toolset (will this run in the browser? dedicated software? can we assume access to out-of-band communications? etc).

Frankly, if you're looking to do this using a "fingerprint" of a user's system (e.g. hash of the serial number of various components) then you're almost certainly fighting a losing battle. You're basically talking about creating something equivalent to a software activation service, like the one Microsoft uses. It's not an easy problem to solve, especially when your code needs to run on machines that you don't trust and can be assumed to be hostile.

Depending on how long you want to make the user wait and your penchant for risk, you may be able to much such a system work if you require users to download and run a piece of software that gathers the information you want, sends it to you and then begins calcuating some unique code based on that information but does so very slowly - think on the order of hours. If you require the user to remain in constant contact with your server while the calculation takes place, you can make it cost a lot of time (and potentially money, depending on how many machines an attacker chooses to wield). Probably overkill and neither bulletproof nor that easy to implement but it's something.

Another option, would be to use a combination of a CAPTCHA (to reduce the likelihood of automated signups) coupled with SMS activation; once the user registers, simply send a message with a unique code to their cell and do not allow a number to be reused. Again, not bulletproof, but the barrier to entry is probably just high enough for now that it, when coupled with limits on how many SMS messages you send per minute, would prevent outright abuse and allow time for suspicious patterns to be investigated.

Share this post


Link to post
Share on other sites
42 minutes ago, Hodor said:

In this scenario, I assume we are playing the role of a gateway, correct? 

So, if that's the case, then the gateway will fund each wallet with a small, minimum amount of xrp.  Were I the gateway, I would have an overall account for an individual, that must be funded prior to my creation of their pre-funded Ripple wallet.  Basically, I am then covering my out-of-pocket cost of pre-funding their wallet.

Or are you thinking of creating an automated service that will open an API up and prefund wallets with a minimum of XRP to try to get increased adoption of XRP?  In that case, abuse is far more difficult to curtail.

I am thinking of this in both terms as a gateway and someone who would like to create a closed loop system that uses ripple accounts to manage transactions without the user needing to know or understand what a ripple address is.  The processes would just fire upon activation of a new wallet an is mostly for experimentation but also for some practical use cases.  One example is to create a new ripple account, activate it, and perform an update settings transaction based upon settings I require for the use case or set by a user via collected form data.  As a gateway I would like to  create a new account for a user, activate it, and set trust-lines for the assets I accept at a conservative default limit to avoid any trouble with deposits if a user has not already created a trust-line. 

35 minutes ago, nikb said:

It's really hard to anser this question. You don't provide any sort of guidelines about what rates of type I and type II errors are acceptable, or any limits on the platform toolset (will this run in the browser? dedicated software? can we assume access to out-of-band communications? etc).

Frankly, if you're looking to do this using a "fingerprint" of a user's system (e.g. hash of the serial number of various components) then you're almost certainly fighting a losing battle. You're basically talking about creating something equivalent to a software activation service, like the one Microsoft uses. It's not an easy problem to solve, especially when your code needs to run on machines that you don't trust and can be assumed to be hostile.

Depending on how long you want to make the user wait and your penchant for risk, you may be able to much such a system work if you require users to download and run a piece of software that gathers the information you want, sends it to you and then begins calcuating some unique code based on that information but does so very slowly - think on the order of hours. If you require the user to remain in constant contact with your server while the calculation takes place, you can make it cost a lot of time (and potentially money, depending on how many machines an attacker chooses to wield). Probably overkill and neither bulletproof nor that easy to implement but it's something.

Another option, would be to use a combination of a CAPTCHA (to reduce the likelihood of automated signups) coupled with SMS activation; once the user registers, simply send a message with a unique code to their cell and do not allow a number to be reused. Again, not bulletproof, but the barrier to entry is probably just high enough for now that it, when coupled with limits on how many SMS messages you send per minute, would prevent outright abuse and allow time for suspicious patterns to be investigated.

I would like to implement a system like this in browser primarily using the ripple library, java-script, and perhaps where needed to run rippled api commands a combination of PHP and Ruby.  I knew that what I was describing would be incredibly complex an I had imagined a situation in which you described where the user would be required to run a downloadable client to sign up to the service but I came to the same conclusions you mentioned (not to mention the time an costs to build an maintain such a system).  

I will take you suggestion under advisement to use a combination of SMS verification with a conservative maximum acceptance rate per minute, CAPTCHAs, and carefully monitor for abuse.  

Edited by Twarden

Share this post


Link to post
Share on other sites
1 hour ago, Twarden said:

I will take you suggestion under advisement to use a combination of SMS verification with a conservative maximum acceptance rate per minute, CAPTCHAs, and carefully monitor for abuse.

Why not a combination of CAPTCHAs and 2FA using google authenticator or Authy? You could stage the registration such that:

1. User registers w/ username, email, password, and CAPTCHA.

2. They verify email address.

3. "For security reasons" they're required to set up TOTP or HOTP 2FA.

4. They're required to log into their account a second time now using the 2FA code. 

5. They have to click a button that says "create wallet" 

6. They enter their 2FA code AGAIN

7. Their Ripple wallet is automatically created. 

 

I think such a process would give the lay user the impression of high-level of security while putting up enough roadblocks to automated registration that it's just not time-efficient for an attacker.

 

Alternatively you could allow unlimited registrations but employ a daily new wallet limit so that there's an automatic and absolute fail safe in the event of an attack. New registrations over the max threshold would be queued for the next 24hr cycle. 

 

Share this post


Link to post
Share on other sites

It doesn't answer your question but: thinking to a gateway, a solution is to create a ripple funded wallet only once the user deposits some money or pays for a service. In this way the gateway can take some fractional money from the deposit to fund XRP. Example: in gatehub, you'll have only the internal wallet unless you deposit some USD or EUR that will be converted into IOUs and some of the funds are removed to fund the initial XRP.

Share this post


Link to post
Share on other sites

@cmbartley Thank you for your suggestion to incorporate 2FA on top of SMS verification as well for setting a variable daily wallet limit before an error message would be produced; I already have a pretty good idea how to build a few pieces of the bigger picture now.

@tulo I have yet to encounter an instance where I have to activate a new account when a client has requested a deposit request as all of my clients are established ripple or cryptocurrency enthusiasts, so I have never encountered this 'issue', but as I mentioned to Hodor this activation system is not primarily being created for an established Gateway's use case.  

I know that many computer illiterate people will roll their eyes into the back of their skulls at the sign of a ripple address an lose interest quickly unless they can quickly see a benefit.  Therefore, I want to attract an audience outside of the crypto-community one day, an in my mind this requires some manual input from the user (such as setting up a new account, funding it, an properly setting trust-lines) to be hidden from the user an instead silently processed in the background  due to the end user's possible perception of a very steep learning curve associated with the benefits of the service provided whereas the cons of the difficulty of set up would outweigh the pros.  I don't want to end up losing anxious/angry clients if they were to become confused during the process of creating an account themselves, funding it (especially difficult for most people who have no idea what ripple/cryptocurrency is), and/or opens a trust-line but then enables the Rippling feature without knowing how it operates an becomes extremely upset when their balances fluctuate.

Thank you all for the great feedback everyone :)  I have a lot to think of now.

Edited by Twarden

Share this post


Link to post
Share on other sites

×