Overview
Calls
- •signup
- •getsalt
- •login
- cors•user/lookup
- cors•<user>/pgp_keys.asc
- •key/add
- •key/fetch
- •session/killall
- •sig/next_seqno
- •sig/post
- •sig/post_auth
- cors•merkle/root
- cors•merkle/block
Other details
getsalt
GET | https://keybase.io/_/api/1.0/getsalt.json
|
|
SAMPLE PARAMS |
email_or_username: "chris"
|
|
SAMPLE OUTPUT |
{
"status": {
"code": 0,
"name": "OK"
},
"salt": "32355c2e7843513463263...",
"csrf_token": "lgHZIDAxNzM1NzR...",
"login_session": "lgHZIDhlY2I0..."
}
|
|
WATCH FOR | "BAD_SIGNUP_USERNAME_TAKEN"
"BAD_SIGNUP_EMAIL_TAKEN"
"BAD_SIGNUP_USERNAME_DELETED"
"INPUT_ERROR"
|
Round 1 of the 2-Round Login Protocol
The Keybase login protocol is two rounds, to prevent replay attacks, and to allow strong randomized salting of passwords.
In the first round of the login protocol, the user presents a username or email address to the server, and the server responds with the salt the user uploaded during signup, and a short-lived random challenge. The salt doesn't change for a given user, but the random challege will always be different, and expires after a few minutes.
The random challege is called login_session
. It's not a trully
random token, but an unforgeable token cryptographically tied to client's
user ID (or email) and a timestamp. This construction saves the server from having
to keep state, but the client can treat the login_session
as
an opaque random token.
If the user or email address does not exist, getsalt
will
reply with a deterministic salt, a function of the parameters. This is so /getsalt
can't be used to test for user membership. (An unnecessary
precaution with usernames, since Keybase is a public directory...)