user/pass auth vs hmac signed for REST API

Question

I know they both prevent the RESTful APIs from abuse. Hmac signed api is commonly used than the other. But I think using user/pass pair for authorization is more security, here's the reason:

1. To sign an api using hmac need a shared secret between client and server. So the server MUST store the secret in a computer readable(reversible) format. If the server get cracked(it's not a small probability event), all it's users are in danger.

2. While using user/pass to authorize client, server could save hashed(with salt) client password to database. Then it is useless after stolen. Plus using tls/ssl to protect the password during transfer, there's no MITM attack.

So the truth is most companies use hmac signed api. Could someone tell me what I've missed?

Answer 1

Here are a few things to think about:

1. For mobile apps: do you stored the user's password on the device? At that point you add risk in case the device is stolen. If you use some form of token based authentication, you store the token and not the password - given how users reuse passwords, any chance to reduce the chance of exposure is good.
2. I wouldn't call salted password hashes useless - they can still be broken as long as the salt is taken as well. Depending on how the hashing is done, even salted, an attacker is likely to have a high success rate.
3. Unless the calling application has 'pinned' the certificate, don't assume safety from MiTM attacks. While it may require unusual circumstances (hacked CA, CA issuing signing certs, etc), it can (and has) happened.

To figure out the right answer though - depends on the specific threats a service is facing, and which risks are considered most important.