[BTC-TC] Virtual Community Exchange [CLOSED]

[odolvlobo]

The bigger improvement however... Issuers can now reply to posted comments.  When an issuer replies the moderator that made the comment will receive an email notification including the content of your reply.

I like it. It would be helpful to quote the vote and comments in the email, too.

[1713922830]

1713922830

[1713922830]

1713922830

[burnside]

It would be nice to have a recovery key like on inputs.io in case you lost your password or 2FA. That way manual recovery is not required, but you need to trust the user to save the key securely.

Here's the rundown:

- Password ... can be reset via forgotten password process.  (sends an email with link... the usual)
- PIN ... write it down!
- Google 2FA ... we display the QR code and secret key before you turn it on.  Either write it down or print it.
- Permanent withdrawal address locks ... do not turn it on unless you really want permanent.

I have a lot (A LOT) of requests pending right now for reset and lock removal requests.  I think I'm around 3-4 days behind.  This is because ~3 days ago a hacker obtained control of a user's email account, requested a PIN reset, and thus used the user's email to take total control of the BTC-TC account.  I've been investigating and trying to find a way to prevent this going forward.  The user was a gmail user, they could have used 2FA on their email and prevented it.  But that is not my focus because other email providers do not have 2FA.  My focus has been trying to figure out a way to prevent reset requests from ending in compromised accounts.

This is especially true with PIN and 2FA reset requests.  It makes me sick to think that someone would turn on 2FA, then because that user's email gets compromised I might hand over full account control via reset request.  Ugh.

The alternative for me is to not allow reset requests.  And I don't think that's a good idea either.

I think instead what I'm going to do is setup an interface on the site where you can request PIN/2FA/Withdrawal Lock resets.  When you submit the request, it will go into a queue.  That queue will have a 30 day countdown.  At intervals during the countdown, emails will be sent out and updates posted in the portfolio page regarding the pending action.  Then at the end of 30 days whatever the requested action is will be taken.

I will also most likely offer an accelerated countdown to users willing to post an escrow of 150% of the value of the contents of the account, to be held for the countdown period in place of the account itself.

However inconvenient this may be, it should take care of 90% or more of the compromised email account issues.  Hackers simply won't be able to quickly profit anymore.

Can anyone else think of improvements on this plan?

Cheers.

[Ukyo]

It would be nice to have a recovery key like on inputs.io in case you lost your password or 2FA. That way manual recovery is not required, but you need to trust the user to save the key securely.

Here's the rundown:

- Password ... can be reset via forgotten password process.  (sends an email with link... the usual)
- PIN ... write it down!
- Google 2FA ... we display the QR code and secret key before you turn it on.  Either write it down or print it.
- Permanent withdrawal address locks ... do not turn it on unless you really want permanent.

I have a lot (A LOT) of requests pending right now for reset and lock removal requests.  I think I'm around 3-4 days behind.  This is because ~3 days ago a hacker obtained control of a user's email account, requested a PIN reset, and thus used the user's email to take total control of the BTC-TC account.  I've been investigating and trying to find a way to prevent this going forward.  The user was a gmail user, they could have used 2FA on their email and prevented it.  But that is not my focus because other email providers do not have 2FA.  My focus has been trying to figure out a way to prevent reset requests from ending in compromised accounts.

This is especially true with PIN and 2FA reset requests.  It makes me sick to think that someone would turn on 2FA, then because that user's email gets compromised I might hand over full account control via reset request.  Ugh.

The alternative for me is to not allow reset requests.  And I don't think that's a good idea either.

I think instead what I'm going to do is setup an interface on the site where you can request PIN/2FA/Withdrawal Lock resets.  When you submit the request, it will go into a queue.  That queue will have a 30 day countdown.  At intervals during the countdown, emails will be sent out and updates posted in the portfolio page regarding the pending action.  Then at the end of 30 days whatever the requested action is will be taken.

I will also most likely offer an accelerated countdown to users willing to post an escrow of 150% of the value of the contents of the account, to be held for the countdown period in place of the account itself.

However inconvenient this may be, it should take care of 90% or more of the compromised email account issues.  Hackers simply won't be able to quickly profit anymore.

Can anyone else think of improvements on this plan?

Cheers.

Hey Burnside,

Normally I don't post in your thread but I do have a suggestion!
I am adding in security questions to both weex and bf. This is a good way to let people prove who they are and a simple db/code add.

Cheers!

[parseval]

It would be nice to have a recovery key like on inputs.io in case you lost your password or 2FA. That way manual recovery is not required, but you need to trust the user to save the key securely.

Here's the rundown:

- Password ... can be reset via forgotten password process.  (sends an email with link... the usual)
- PIN ... write it down!
- Google 2FA ... we display the QR code and secret key before you turn it on.  Either write it down or print it.
- Permanent withdrawal address locks ... do not turn it on unless you really want permanent.

I have a lot (A LOT) of requests pending right now for reset and lock removal requests.  I think I'm around 3-4 days behind.  This is because ~3 days ago a hacker obtained control of a user's email account, requested a PIN reset, and thus used the user's email to take total control of the BTC-TC account.  I've been investigating and trying to find a way to prevent this going forward.  The user was a gmail user, they could have used 2FA on their email and prevented it.  But that is not my focus because other email providers do not have 2FA.  My focus has been trying to figure out a way to prevent reset requests from ending in compromised accounts.

This is especially true with PIN and 2FA reset requests.  It makes me sick to think that someone would turn on 2FA, then because that user's email gets compromised I might hand over full account control via reset request.  Ugh.

The alternative for me is to not allow reset requests.  And I don't think that's a good idea either.

I think instead what I'm going to do is setup an interface on the site where you can request PIN/2FA/Withdrawal Lock resets.  When you submit the request, it will go into a queue.  That queue will have a 30 day countdown.  At intervals during the countdown, emails will be sent out and updates posted in the portfolio page regarding the pending action.  Then at the end of 30 days whatever the requested action is will be taken.

I will also most likely offer an accelerated countdown to users willing to post an escrow of 150% of the value of the contents of the account, to be held for the countdown period in place of the account itself.

However inconvenient this may be, it should take care of 90% or more of the compromised email account issues.  Hackers simply won't be able to quickly profit anymore.

Can anyone else think of improvements on this plan?

Cheers.

Hmm...  a couple of things, maybe.

You could send a text message via Twilio if the user has a mobile phone on their account, and have the user respond with a confirmation code.  Once that code is sent, the password reset email could be forwarded to the client.  This has the benefit of being able to automate.

Or you could require users to sign a message using the bitcoin address associated with the account.  If that's successful, the email can be sent to reset the password.


edit:  I hate security questions and answers, because the same ones seem to be used for every site, which isn't very secure.  Chances are good that if the attacker got access to the user's email address, he did it via the security questions and a little googling.    I always enter a random string into the answer field and save it in my password manager. 

[Ukyo]

Hmm...  a couple of things, maybe.

You could send a text message via Twilio if the user has a mobile phone on their account, and have the user respond with a confirmation code.  Once that code is sent, the password reset email could be forwarded to the client.  This has the benefit of being able to automate.

Or you could require users to sign a message using the bitcoin address associated with the account.  If that's successful, the email can be sent to reset the password.


edit:  I hate security questions and answers, because the same ones seem to be used for every site, which isn't very secure.  Chances are good that if the attacker got access to the user's email address, he did it via the security questions and a little googling.    I always enter a random string into the answer field and save it in my password manager. 

I built up a list of about 10~20 so far. Will keep adding.
Was also going to allow custom q/a's too.

[Rannasha]

It would be nice to have a recovery key like on inputs.io in case you lost your password or 2FA. That way manual recovery is not required, but you need to trust the user to save the key securely.

Here's the rundown:

- Password ... can be reset via forgotten password process.  (sends an email with link... the usual)
- PIN ... write it down!
- Google 2FA ... we display the QR code and secret key before you turn it on.  Either write it down or print it.
- Permanent withdrawal address locks ... do not turn it on unless you really want permanent.

I have a lot (A LOT) of requests pending right now for reset and lock removal requests.  I think I'm around 3-4 days behind.  This is because ~3 days ago a hacker obtained control of a user's email account, requested a PIN reset, and thus used the user's email to take total control of the BTC-TC account.  I've been investigating and trying to find a way to prevent this going forward.  The user was a gmail user, they could have used 2FA on their email and prevented it.  But that is not my focus because other email providers do not have 2FA.  My focus has been trying to figure out a way to prevent reset requests from ending in compromised accounts.

This is especially true with PIN and 2FA reset requests.  It makes me sick to think that someone would turn on 2FA, then because that user's email gets compromised I might hand over full account control via reset request.  Ugh.

The alternative for me is to not allow reset requests.  And I don't think that's a good idea either.

I think instead what I'm going to do is setup an interface on the site where you can request PIN/2FA/Withdrawal Lock resets.  When you submit the request, it will go into a queue.  That queue will have a 30 day countdown.  At intervals during the countdown, emails will be sent out and updates posted in the portfolio page regarding the pending action.  Then at the end of 30 days whatever the requested action is will be taken.

I will also most likely offer an accelerated countdown to users willing to post an escrow of 150% of the value of the contents of the account, to be held for the countdown period in place of the account itself.

However inconvenient this may be, it should take care of 90% or more of the compromised email account issues.  Hackers simply won't be able to quickly profit anymore.

Can anyone else think of improvements on this plan?

Cheers.

Hmm...  a couple of things, maybe.

You could send a text message via Twilio if the user has a mobile phone on their account, and have the user respond with a confirmation code.  Once that code is sent, the password reset email could be forwarded to the client.  This has the benefit of being able to automate.

Or you could require users to sign a message using the bitcoin address associated with the account.  If that's successful, the email can be sent to reset the password.


edit:  I hate security questions and answers, because the same ones seem to be used for every site, which isn't very secure.  Chances are good that if the attacker got access to the user's email address, he did it via the security questions and a little googling.    I always enter a random string into the answer field and save it in my password manager. 

Agreed on the security Q&A stuff. It's a poor way to add password recovery. If the question is answered truthfully, it's often easy to guess or find out for a dedicated attacker. In addition, if the computer is compromised when the account is registered, a keylogger can easily capture the security answer.

A text message function would be much better. The user can enter their cellphone # when they register (or at a later point), receive a text message with a code to verify that he controls the provided phonenumber. After activating this function, password resets are only made when a text message code is sent and entered correctly. This could still cause a problem if someone loses their phonenumber, but pretty much every provider will supply a replacement SIM card for the same number to their customers. The chance of someone permanently losing access to their cellhpone number is very low.

[burnside]

Hey Burnside,

Normally I don't post in your thread but I do have a suggestion!
I am adding in security questions to both weex and bf. This is a good way to let people prove who they are and a simple db/code add.

Cheers!

Definitely appreciate your input.  I worry about information leakage from other sources (compromised sites, public record, facebook posts, etc.) and about keylogger compromises when signing up.

Custom questions helps significantly, but most people are going to slip into one of their old standby's fearing that they won't remember their response correctly when you really need it.  (this is me.)  For example, I'll get the question "where was the first concert you attended?".  I answer based on the rock concert with my gf when I was in high school.  Then a year later I need to recover the account and I'm thinking about the first orchestra concert I went to when I was a kid, totally forgetting the one in high school.  That doesn't even get into the spelling and other data entry issues.  Like asking about my favorite teacher... did I put in her full name or just her last name... crap, can't remember and I had two favorites, which one was my favorite that day?

Agreed on the security Q&A stuff. It's a poor way to add password recovery. If the question is answered truthfully, it's often easy to guess or find out for a dedicated attacker. In addition, if the computer is compromised when the account is registered, a keylogger can easily capture the security answer.

A text message function would be much better. The user can enter their cellphone # when they register (or at a later point), receive a text message with a code to verify that he controls the provided phonenumber. After activating this function, password resets are only made when a text message code is sent and entered correctly. This could still cause a problem if someone loses their phonenumber, but pretty much every provider will supply a replacement SIM card for the same number to their customers. The chance of someone permanently losing access to their cellhpone number is very low.

Whatever I do has to be something that works well internationally.  Is the SMS approach easy to support globally?  I'll be honest, one of the reasons I have been avoiding this is because I'm not sure people will want to be giving us their phone numbers.  It's one of those things I don't even want to have, because it's a liability to have that stuff on file if we're ever compromised.  Hope that makes sense.

Cheers.

[parseval]

Whatever I do has to be something that works well internationally.  Is the SMS approach easy to support globally?  I'll be honest, one of the reasons I have been avoiding this is because I'm not sure people will want to be giving us their phone numbers.  It's one of those things I don't even want to have, because it's a liability to have that stuff on file if we're ever compromised.  Hope that makes sense.

Cheers.

Twilio is international, but different rates apply for different countries I think.  However, it's generally around $0.01 usd per text message.  

http://www.twilio.com/sms/pricing/


If you don't want to collect additional user information, use what you already have, which is the public withdrawl address.   The user should be able to sign a message using their bitcoin client to prove their identity.  It's how the Bitcoin OTC/WoT does it.  This might have some barrier for the average user, but instructions can be posted on how to sign a message.

[dexX7]

If you don't want to collect additional user information, use what you already have, which is the public withdrawl address.   The user should be able to sign a message using their bitcoin client to prove their identity.  It's how the Bitcoin OTC/WoT does it.  This might have some barrier for the average user, but instructions can be posted on how to sign a message.

Right now, to my knowledge, an user is identified by an email address.


Feature request: make asset news accessible via API. Please.. And I'd appreciate a reduction of cache time, but you already addressed that, I think.

[btharper]

I have a sizeable amount of coins spread out over my portfolio on your exchange, but moving them with is slow which in turn inhibits my ability to trade. Could you add support for Inputs.io as I have many coins stored there and that would greatly increase trading productivity.

It's being looked at as a way to enable quicker deposits.

I do not think it would speed up withdrawals much, given our manual processing requirement.

Cheers.

My impression of the service is that transfers to/from Inputs.io are instant to supported services and all the balances are stored with Inputs.io and mixed. The server would no longer have any reason to be running bitcoind and wallet security is someone else's problem. However, the obvious counterparty risk applies; while I personally trust TF, more money on Inputs makes it a nicer target to crack.

[Exocyst]

If you don't want to collect additional user information, use what you already have, which is the public withdrawl address.   The user should be able to sign a message using their bitcoin client to prove their identity.  It's how the Bitcoin OTC/WoT does it.  This might have some barrier for the average user, but instructions can be posted on how to sign a message.

Right now, to my knowledge, an user is identified by an email address.


Feature request: make asset news accessible via API. Please.. And I'd appreciate a reduction of cache time, but you already addressed that, I think.

Or allow a user to link to a bitcoin-otc identity, then they could sign with the GPG key or wallet address associated with their identity. The more options there are the better it is for users.

[burnside]

There was an issue with the oAuth API approval page not properly redirecting following an approval.  It should be taken care of now.  Sorry about that!  The new realtime tab code was interfering with the header redirect call.

Cheers.

[Rannasha]

There was an issue with the oAuth API approval page not properly redirecting following an approval.  It should be taken care of now.  Sorry about that!  The new realtime tab code was interfering with the header redirect call.

Cheers.

Any chance for an 'oob' page with a verified code displayed for standalone clients that can't handle callbacks?

[burnside]

There was an issue with the oAuth API approval page not properly redirecting following an approval.  It should be taken care of now.  Sorry about that!  The new realtime tab code was interfering with the header redirect call.

Cheers.

Any chance for an 'oob' page with a verified code displayed for standalone clients that can't handle callbacks?

You bet.  If you pass in a callback of "oob" now you should get the verifier code as just a text response when the user authorizes the access request.

Totally untested at this point.  Give it a try and let me know how it goes. 

[Lohoris]

edit:  I hate security questions and answers, because the same ones seem to be used for every site, which isn't very secure.  Chances are good that if the attacker got access to the user's email address, he did it via the security questions and a little googling.    I always enter a random string into the answer field and save it in my password manager. 

Agreed on the security Q&A stuff. It's a poor way to add password recovery. If the question is answered truthfully, it's often easy to guess or find out for a dedicated attacker. In addition, if the computer is compromised when the account is registered, a keylogger can easily capture the security answer.

THIS.

Security questions are a horrible horrible and stupid practice that should be outlawed.

[matt4054]

edit:  I hate security questions and answers, because the same ones seem to be used for every site, which isn't very secure.  Chances are good that if the attacker got access to the user's email address, he did it via the security questions and a little googling.    I always enter a random string into the answer field and save it in my password manager.  

Agreed on the security Q&A stuff. It's a poor way to add password recovery. If the question is answered truthfully, it's often easy to guess or find out for a dedicated attacker. In addition, if the computer is compromised when the account is registered, a keylogger can easily capture the security answer.

THIS.

Security questions are a horrible horrible and stupid practice that should be outlawed.

+1 googolplex to THIS!!!

I think I almost died of anger the day that I had to bloat my Apple account with 4 (!) bogus (in)security Q+As, because my "algorithm" for generating answers (regardless of the question, actually) wasn't prepared to give 4 different ones, so I had to suffix them. Also, since the answer isn't related to the question at all using my "survival workaround" to forced security questions, I can't know the order for sure.

Twice already I had to answer these "security questions" over the phone and I loved it because they always contain/derive the words "stupid insecure" + something*. The worst is that you can't even leave it blank to avoid compromising your security.

I think our kids in 3 generations are going to laugh at how stupid their elders were with data security... and we are just a bit ahead of time.

* well not really, otherwise I'd compromise my security even further by publishing this, but you get the tone...

[dexX7]

Any chance for an 'oob' page with a verified code displayed for standalone clients that can't handle callbacks?

You can use a callback to something non existant and manually copy the verifier from your browser. The callback redirects for exampe to http://XXXX/ and this looks like:

Code:

http://XXXX/?oauth_token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&oauth_verifier=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Another workaround I tested was to open a TCP connection and set the callback uri to your localhost and port where the TCP connection is listening.

A landing page on btct.co would be a very nice idea though!

[parseval]

I posted some sample code a while ago, it works with OOB, just grab the verifier code from the URL string like was mentioned above:

http://dpaste.com/hold/1197404/

edit:

I was thinking about creating a python library to wrap the BTC-TC API.  Who would find such a thing useful?

[Rannasha]

Any chance for an 'oob' page with a verified code displayed for standalone clients that can't handle callbacks?

You can use a callback to something non existant and manually copy the verifier from your browser. The callback redirects for exampe to http://XXXX/ and this looks like:

Code:

http://XXXX/?oauth_token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&oauth_verifier=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Yeah, that's what I was doing. Using "oob" before, it would try to redirect to a non-existent BTCT page and I would copy/paste the verifier from the address bar.

The new landing page works fine, much better than copy/pasting from an address bar from a user-experience PoV.

I believe that the standard guideline for "oob" landing pages is to have a page in the layout of the site that says something like "Copy/paste this code into the box provided by the application you're trying to access <website> with" and then prominently showing the verifier code. That would be a nice upgrade from the current, minimalistic page

[burnside]

Any chance for an 'oob' page with a verified code displayed for standalone clients that can't handle callbacks?

You can use a callback to something non existant and manually copy the verifier from your browser. The callback redirects for exampe to http://XXXX/ and this looks like:

Code:

http://XXXX/?oauth_token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&oauth_verifier=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Yeah, that's what I was doing. Using "oob" before, it would try to redirect to a non-existent BTCT page and I would copy/paste the verifier from the address bar.

The new landing page works fine, much better than copy/pasting from an address bar from a user-experience PoV.

I believe that the standard guideline for "oob" landing pages is to have a page in the layout of the site that says something like "Copy/paste this code into the box provided by the application you're trying to access <website> with" and then prominently showing the verifier code. That would be a nice upgrade from the current, minimalistic page

I'll see what I can do.