list the Coinapult wallet

[g-p-g]

Happy to answer any questions about the wallet and service.

[g-p-g]

Is there any timeline for this? Also, would you consider higher resolution screenshots for retina displays?

[saivann]

@g-p-g There is quite a lot of wallets waiting for being added, I should be able to spend time on this very soon.

[g-p-g]

In that case is it okay to leave this PR with merge conflicts until some decision is made? I have done adjusts a couple of times regarding conflicts due to new translations coming in (which is good, bitcoin.org is improving all the time), but it takes some time and I'm not sure if I should bother doing that for now.

[saivann]

@g-p-g Sure, no problem there

[saivann]

@g-p-g Just tested the service, thus far one concern I have is a bit weak authentication - coinapult accepts weak passwords (only 6 letters), which increases the risk of people choosing too simple words, while at the same time (at least to my observation), not warning the user to enable 2FA.

Do you think you can put some very visible banner (e.g. a warning "Enable 2FA" line on the walllet) to incentivize your users to enable that feature? And maybe require longer passwords?

Regarding the pull request, there is no mention of an insurance on the coinapult website:
https://www.google.ca/webhp?ie=UTF-8#q=insurance+insured+site:coinapult.com
Accordingly, can you replace "checkfailcontrolthirdpartyinsured" by "checkfailcontrolthirdparty"?

Can you rename decentralization: "checkfaildecentralizecentralized" to validation: "checkfailvalidationcentralized" ?

[g-p-g]

Regarding long passwords, I'm really unsure about increasing its size for the sake of making it longer. What will happen is that people that don't care about it will either repeat initial letters or insert 00, or something that doesn't increase the password strength in practice. You're not the first to suggest that, we might reconsider this at some point, but we don't have any evidence that people will actually put stronger passwords just because you increase the minimum length. Right now it checks the passwords against a list of known passwords before proceeding, and rejects it in case it's present in that list.

About enabling 2FA maybe we could send such reminder with the email you receive after account creation, what do you think about that instead?

We're working on insurance but you're right, we don't have anything public and final at this point. Thanks for the feedback.

[saivann]

@g-p-g Requiring long / difficult passwords seems to be the rule for most online services, unless you have multiple authentication and strong ID verification. But I certainly cannot back the claim that it makes a strong difference - but in any case that cannot harm, except for user-friendlyness. I have noticed that coinapult blocks very weak passwords, that's great.

Email on setup for 2FA I think is a good step forward, although I have the impression that a non-obtrusive well designed persistent reminder in the wallet would do wonders.

[g-p-g]

I think that would provide a strong reminder for using 2FA, yes, but we still need to figure out how exactly this non-obtrusive well designed reminder would be in terms of this specific website. I'll ask for opinions internally to check if there are good suggestions for that, thanks again.

[saivann]

@g-p-g Can you notify here once coinapult has set some 2FA reminding system? I think once done, this would put the wallet on the same line than Coinbase and Coinkite.

Otherwise, I haven't seen other reasons to not include coinapult with the current scores. Public feedback seems OK, no weak ssl, owners of the business are public and long-term involved in the space, coinapult seems to have some backing and funding, and the features I have tested, including 2FA and address rotation, worked as expected.

Therefore once the 2FA reminder is set, unless this pull request receives new comments that require consideration, I will leave an extra 2 week for reviews and comments before merging the pull request.

[g-p-g]

@saivann cool, thanks! I'm checking what we can do regarding 2FA notifications and will update once it goes live.

[g-p-g]

@saivann we have been talking internally about this and there are a couple of things we'll be doing, some will get into our next release 1 week from now and others will take longer to become available. For now we'll be introducing a newsletter that mentions 2FA and why it would be good to enable it, this email would be received right after verifying the email (and since this is a newsletter the user would be free to disable future emails). Also, we'll start raising user awareness about 2FA availability and usage over twitter/facebook. For the next release we might include an updated interface that would point out that 2FA is not enabled in the first page right after login.

[saivann]

@g-p-g Just in case this information can be useful to you, you might want to consider that, at least as far as Canada is concerned, the latest anti-spam law prevents you to use an "opt-out" newsletter. The user must explicitely opt in for the newsletter and it has to be unselected by default. So you may want to speak to your lawyers about that before mixing up newsletter emails with indidivual emails sent to users for the functionning of the service they're using.

[g-p-g]

@saivann thanks for the info, will check the wording and what we can do about that. That email with 2FA information is a welcome email mentioning the services, so it doesn't fit into a newsletter by itself.

[saivann]

@g-p-g Regarding the "send bitcoins by email" feature, to my understanding, you're sending redeemable irreversible payments in plaintext by email. However once the recipient created an account, subsequent payments are safe, as they only imply sending and receiving bitcoins between registered users.

Given that the first payment to a non-registered user is more vulnerable and carries higher risk of becoming an attack vector, how would you feel with preventing large payments by email to non-registered users? Or do you already have such limit in place?

[g-p-g]

@saivann when you send bitcoins by email, internally we have an internal bitcoin address associated to it owned by Coinapult. In that sense it can be reversed if the user doesn't upgrade his account in order to receive it. Maybe you're talking about someone getting access to the recipient's email? Is that different from someone getting access to the user's email after he got an account and didn't enable 2fa? We have limits in place and you can't send large amounts in any case except you're a verified merchant.

[saivann]

@g-p-g No I'm refering to bitcoins sent by email to non-registered users. In this case, the email contains redeemable payment that doesn't require any authentication. Whoever gets access to that email can create an account at coinapult and redeem the payment. As opposed to payments between existing coinapult users which require password (and optional 2FA) authentication to spend.

[g-p-g]

@saivann exactly, that's the scenario I'm mentioning. Suppose you have an account without 2fa, and manage to get access to the email as well (like you're mentioning). You can request a password reset and gain access to the account, the issue is the same.

[saivann]

:sigh: That's something I worry about account recovery features that rely on email only, email accounts are being hacked all the time. IIRC Coinbase is also set this way and probably other web wallets too so it's not a specific point to coinapult. I don't know what is worse between the risk of users losing their passwords or the risk of users having their email accounts compromised on the long run, but I wish there would be account recovery options less fragile than just having access to an email account...

Maybe at some point asking for mandatory 2FA as soon as the account reaches a certain balance would make sense as a low-barrier-of-entry-adaptative-authentication? I think Coinbase uses a similar approach.

[g-p-g]

It's good to be worried about it, it's a convenience feature that introduces these kind of issues. But I'm even more worried about very common systems that rely on 4 digit pins to secure things.

[saivann]

I am probably not aware of all individual cases, but thus far PIN protections that I've seen are only used as complementing authentication methods. So one needs to have already compromised a device to try breaking the PIN protection, and usually will be locked out after very few attempts.

From this perspective, if some attacker gets access to my mobile or computer and it's got a PIN protected wallet with aggressive lock down, I am better protected than if some attacker gets access to my email account and I've got a web wallet with account recovery by email.

In either case I'll first check what is the state of things with other listed web wallets so I can see if coinapult is any worse than what we have now. Otherwise, I haven't found any other points worth mentioning, 2FA is correctly reminded by email now!

[g-p-g]

Ok, is there anything else I can do?

[saivann]

A quick update on the last point (account recovery by email); Circle asks users to answer security questions when recovering their account and Coinkite only sends a password hint by email. Coinbase seems to be the only service to allow resetting the password by email with no additional authentication. I am currently asking them if 2FA becomes mandatory as soon as the account reaches a certain threshold. Edit: Xapo also seems to allow users to reset their password only with access to an email address.

[luke-jr]

@saivann I would find it annoying as a user if Coinbase made 2FA mandatory for mere logins.

[saivann]

@luke-jr In case my last comment could be misleading, I am not saying they should use it in a certain way (e.g. I think some services ask 2FA mostly only when spending). I am only asking details on how they actually work, so I can know if compromising a high-value Coinbase account remains possible by only having access to the user's email account.

[g-p-g]

The PR no longer has conflicts, again.

[saivann]

@g-p-g It seems most other web wallets have measures in place to prevent users to lose funds if their email account is compromised. Coinbase confirmed to me that account recovery by email will only work when the request comes from a recognized device for accounts with a balance over 1000 USD.

This being said, Xapo apparently is the only exception and since this is not a current requirement, I am commenting in favor of including Coinapult. However, I'd like to encourage you to put in place more demanding authentication for account recovery than only email verification and set spending limits on "bitcoins by email/SMS" between unregistered users.

I plan to submit something similar to "Spending bitcoins only by having access to the user email account is not possible" as a requirement soon. Unless there is opposition to that new requirement, Coinapult's listing would be short lived, although it could be resumed as soon as the wallet meets the requirement.

[saivann]

In the absence of critical feedback, this pull request will be merged on January 22th.

[g-p-g]

@saivann thanks for the update.

I'm guessing you meant the opposite so only accounts with less than 1k USD can get a password reset through email from this other service you're mentioning, right?

We're always improving the various different services we offer, and several others that are not directly visible to end users. So it's quite likely that we'll soon deploy improvements in this specific area you're commenting on; you can also send questions to support@coinapult.com regarding the status on specific features.

[saivann]

@g-p-g Thanks!

I'm guessing you meant the opposite so only accounts with less than 1k USD can get a password reset through email from this other service you're mentioning, right?

No actually regarding the approach used by Coinbase, they're allowing account recovery by email for all accounts, but as soon as the account reaches 1k USD, account recovery will only work when done from a device that was previously verified (successful login and email verification), I guess they're either keeping a whitelist of IP addresses or some cookie in the browser.

[g-p-g]

I can't tell if there's any actual security on that approach or if it's trying to be secure by being obscure, I certainly don't know what's done there based on that description. In any case that's not entirely relevant, we're not trying to mimic it and instead we'll actually increase the security for password resets. Thanks again for going through all this and for providing a couple of useful suggestions.