Properly securing your bitcoin web API

[greBit]

I was just hoping for a bit of feedback regarding a proposed method for securing access to a state-less web API server which could help protect bitcoins.

I would like it such that each request is signed by the client, in such a way that I can guarantee that the issuer of the request is a valid user of our site.

Server and client have a shared secret - i.e. the hashed password of the user, so...

• Server sends a random nonce value to the client
• Client constructs a signing key K as (nonce,hashed_password)
• Client signs each request with key K
  
  • e.g. ('delete image_x',user_id,request_signature)
• Server then checks the signature as being valid for every request before processing it.

Are there any obvious flaws?

cheers!

[Come-from-Beyond]

Is it via HTTPS? If not and the nonce is not changed everytime then a man-in-the-middle can repeat a client's message. If it's something like "Pay X to Y" then it could be dangerous.

[acoindr]

1. most obvious is limiting attempts getting it wrong before locking user out, otherwise brute force may be option
2. how secure is the database containing the hashed password? if the db can be compromised (sql injection etc.) then the password might be brute forced if not very long or not hashed in secure way
3. who has access to the server? if a hosting company then any weak link there means compromise

The method you describe seems secure, but that's just one piece of the overall puzzle of course.

[BkkCoins]

How does the server verify the signed response without having a private key? You said it sends a nonce out but it can't check the signature coming back without a matching key.

The way I did this was have the client generate a key pair and send the public key to the server. this assumes the first login is genuine but after that all subsequent data can be verified.