can this be installed headless, or does a gui with intellij need to be on the hosted machine?

Entering an invalid PGP key on signup or the settings page results in an uncaught exception.

[error] p.c.s.n.PlayDefaultUpstreamHandler - Cannot invoke the action
org.bouncycastle.util.encoders.DecoderException: unable to decode base64 data: invalid characters encountered at end of base64 data

Entering no PIN, e.g. "", gives:

Two factor auth not configured.

Entering a string, e.g. "a", gives:

Server Error: Execution exception[[NumberFormatException: For input string: "a"]]

Entering an invalid PIN, e.g. "0", gives:

Invalid token.

All of them should give Invalid token. on the PIN entry page.

We don't accept passwords under 12 characters, but it seems like people attempt to use them often. We should let them know that their password won't be accepted using a client side check before they submit it and find out that it's too short.

Right now it's strangely positioned in the middle of the form. It should be beside the label.

We need the frontend server to have very limited permissions on the database. We can improve security significantly that way.

• Use a separate user for the frontend and for the wallet
• Use randomized user ids to minimize exposure in case of a frontend breach
• Make sure that regular user functions don't work on user 0
• Remove find_user_by_email
• Authenticate password changes in postgres
• Send password resets from the wallet instead of the frontend
• Don't allow access to the free money api in prod

Instead of relying on the frontend to create a log of an access such as user authentication, the database function itself should create the log message. Something to keep in mind is that the function must commit successfully, possibly returning false or an unauthorized state, as if it throws an exception and rolls back, then the log message will not get written either.

follow up from #29

When you don't include an out parameter, the function still works, but the column name defaults to the name of the function. We get rid of some boilerplate code this way.

Follow up from #29

I had written this in the code review for #29 but it makes more sense to have a separate issue.

I think we need to return the bids and asks in a single select query or the order books could appear inconsistent. For example, if we retrieve the bids first and then a sell order for less than the highest bid is committed before we query the asks, we could see an ask lower than the highest bid as well as bids that were already matched by this ask. This does not affect our database but it would look wrong to users and possibly affect automated trading bots. I suggest we use a function like this to get the order books atomically:

CREATE AGGREGATE array_agg_mult (anyarray) (
    SFUNC     = array_cat
   ,STYPE     = anyarray
   ,INITCOND  = '{}'
);

create function 
  orders_depth(
    a_base varchar(4),
    a_counter varchar(4),
    out asks numeric(23,8)[],
    out bids numeric(23,8)[])
  as $$
    select (
      select array_agg_mult(array[array[price, amount]]) from open_asks(a_base, a_counter)
    ), (
      select array_agg_mult(array[array[price, amount]]) from open_bids(a_base, a_counter)
    );
$$ language sql stable cost 100;

This buttons would be on the sign up, change password and reset password pages.

This also requires that we let the user hide and reveal the password in the password field.

I stated here: #38 but we should make a pretty diagram and put it in the wiki

https://txbits.uservoice.com/forums/264884-general/suggestions/6458533-clearer-interface

#81

We can put these things:

    LANGUAGE plpgsql SECURITY DEFINER
    SET search_path TO public, pg_temp

before the function body. We should do that eventually to make the function definitions cleaner.

It's unnecessary. We should be using http error codes instead.

There is one case that leads to somewhat confusing results. When the exchange is running and we manually send money from an unassociated address to another unassociated address on the same wallet, it creates a send and a receive in bitcoind, but the exchange pickes up only the receive and thinks "hey, free money, let's give it to user 0", but it doesn't know that the money came from user 0 to begin with. Unassociated sends transactions are not reflected in the database AFAIK.

We might have to restructure that page. I don't see how else we can fit larger numbers.

It's not a big deal right now as we are still testing, but we should remember to add CSRF protection on the login form.

When a user doesn't have two factor auth set up, we can do an email loop through the user trust service to confirm withdrawals. When they do have it, the wallet should confirm the two factor auth token itself. This will make the frontend completely untrusted.

The wallet actor uses getbalance from bitcoind to determine if the wallet has enough funds to process withdrawals and if a transfer should be made to cold storage. Balance could be inaccurate from double spends or transaction malleability. This was fixed in Bitcoin in the following pull request: bitcoin/bitcoin#3671 Bitcoin and Litecoin are safe but altcoins may not have this patch and would need to be patched or the wallet actor needs to be modified to not get the balance from the daemon.

The deposits_crypto table has a unique constraint on tx_hash but multiple rows are needed if there is one Bitcoin transaction to multiple deposit addresses on the exchange as both deposits would have the same transaction hash.

• translate errors
• translate javascript messages with https://github.com/julienrf/play-jsmessages
• translate marketing page

Provide a two factor auth recovery mechanism

Will you able to change the AGPL to MIT License?
I think it will be more lovely project to work on and put it into production stage.

We should advise users to generate passwords with a password manager or make up random passwords and then write them down.

Our current content security policy is:

default-src 'self' data: https://www.google-analytics.com https://*.uservoice.com; script-src 'self' 'unsafe-eval' https://www.google-analytics.com https://*.uservoice.com; style-src 'self' data: 'unsafe-inline'; font-src 'self' data:

(The development CSP is slightly different because Google Analytics and User Voice load over http when the page is served over http.)

Our CSP is limited by:

• handlebars that uses dynamically constructed functions
• uservoice that uses inline styles
• uservoice that uses data: urls for a lot of things
• google analytics and uservoice that require loading of external javascript
• google analytics and uservoice that require data: urls

We should consider tightening the CSP by not using Google Analytics, User Voice and Handlebars or finding secure workarounds to use them with a stricter CSP.

We have a lot of duplicated sql code that looks like this:

  if a_uid = 0 then
    raise 'User id 0 is not allowed to use this function.';;
  end if;;

  if a_api_key is not null then
    select user_id into a_user_id from users_api_keys
    where api_key = a_api_key and active = true and list_balance = true;;
  else
    a_user_id := a_uid;;
  end if;;

  if a_user_id is null then
    return;;
  end if;;

We need to abstract that into a more general function. pgsql is pretty awkward to work with, but I think we can deduplicate some of this code. The awkward part is that each type of permission is a column instead of a row. Maybe if we change that, it will make this task easier.

We should set some meta tags to improve our SEO rankings.

We should use something else to keep it separate from the public facing api.

If someone types in the wrong email address when registering, they won't realize and will wait indefinitely for the email, which will cause a stuck user and the user will have to be restarted.

The current message is "Thank you. Please check your email for further instructions"

It should say "Thank you. An email has been sent to [email protected]. Please check your email for further instructions"

If users have 2 factor:

As long as the user has access to their password + 2 factor, they should be able to change their PGP key. As long as they have access to their PGP key, they should be able to reset they password and + 2 factor.

If they have no 2 factor:

As long as they have access to the email address or password, they should be able to set up a PGP key or 2 factor.
As long as they have access to the email, they should be able to reset the password.

How do you login as admin or access the database?

In application.conf and Mailer.scala, the link http://localhost:9000/reset/ is sent for sendAlreadyRegisteredEmail but the link should be http://localhost:9000/reset without a trailing slash. The slash needs to be there when a token is present so changing url.passwordreset will only work if Mailer.scala is changed to add a slash before the token.

remove SecureSocialTemplates.scala and txbitsUserService.scala

The signup page at /signup works as expected but the form on the homepage gives:

Invalid token found in form body