Have not read the thread but 1st observations are:
1. Collecting account info in registration over http == bad
2. Registration says, now go logon; come-on why didnt you set the session cookie?
3. Collecting user id and password over http for logon means it can be taken.
4. Session cookies over http mean they can be taken even if you send creds over https.
5. Tried to logon after registration and was told account would lockout in 5 tries, sure I entered right password why cant I log in.
6. Tried to logon again still said bad password and lockout in 5 times, shouldnt it be 4?
More:
1. Workflow for password reset is broken, after entering my reset password was redirected to the reset password form, entered user id again got new password again, had to close that tab and navigate back since this form looks like it was intended to be in a layer.
2. My IP was banned, I tried under 10 times to log in; glad you ban on suspicious activity but I wasnt doing anything other than trying to log on, check your thresholds.
3. No account providence stuff was done, if there is money in the accounts you want to make sure they can get back in if they mess up so you need to do this.
4. Learn from the mt gox fiasco, collect enough information you can validate providence if you have to "recover" accounts.
If you would like to discuss common authn mistakes in implementations like these PM me and we can discuss in detail.
The livenet cookies and form submissions will be over HTTPS. The SSL is assigned to "campbx.com", and using it on "testnet.campbx.com" triggers ominous-sounding messages in many browsers. Due to this reason we are on HTTP for the trial.
Account providence fields are a good idea - we have added them to the feature list.
Your IP ban has been reset so you should be good to login again. The password is not allowed quotes / apostrophes.