io7m | single-page | multi-page | epub | Idstore User Manual 2.0.0
9.4. Admin API
Previous
9. Security
Up
Front Matter
Next

# 9.5. User API

- 9.5.1. Login
  - 9.5.1.1. Potential Attack: Online Brute Force
    - 9.5.1.1.1. Description
    - 9.5.1.1.2. Mitigation
- 9.5.2. Email Additions
  - 9.5.2.1. Potential Attack: Spam
    - 9.5.2.1.1. Description
    - 9.5.2.1.2. Mitigation
- 9.5.3. Email Removals
  - 9.5.3.1. Potential Attack: Lockout
    - 9.5.3.1.1. Description
    - 9.5.3.1.2. Mitigation
- 9.5.4. Password Resets
  - 9.5.4.1. Potential Attack: Spam
    - 9.5.4.1.1. Description
    - 9.5.4.1.2. Mitigation

## 9.5.1. Login

## 9.5.1.1. Potential Attack: Online Brute Force

## 9.5.1.1.1. Description

1
An attacker could automate login requests to the user API in an attempt to repeatedly try to guess the password of a given account, or simply to try to probe all accounts for weak passwords.

## 9.5.1.1.2. Mitigation

1
The idstore server currently applies configurable rate limiting to login operations. The default setting is to require that no more than one login request be made from a given IP address in a given five-second duration. Additionally, a configurable delay is automatically applied to every login operation so that, by default, every login attempt takes at least one second to complete.
2
The idstore server uses constant-time algorithms for checking password hashes in the hope that this will avoid leaking timing information to clients. The idstore server should NOT be considered timing-invariant in the general case.

## 9.5.2. Email Additions

## 9.5.2.1. Potential Attack: Spam

## 9.5.2.1.1. Description

1
An attacker with access to a compromised user account could request the addition of lots of random email addresses to the account. The intent of this attack would be to get the idstore server to send lots of mail to random addresses, either to annoy the owners of those addresses, or to try to get the MTA associated with the server blacklisted as a sender of bulk unsolicited mail.

## 9.5.2.1.2. Mitigation

1
The idstore server currently applies configurable rate limiting for email verifications, with the suggested default being one verification allowed every ten minutes. In this case, the limit is applied on a per-user basis, so a compromised account trying to produce a flood of verification requests does not affect any other user's ability to verify email addresses.
2
Additionally, a user may have at most 10 in-progress email verifications at any given time. Any attempt to create another email verification beyond this limit will be denied by the security policy. The user will have to either manually clear the verifications (by denying the requests from an email account under the user's control), or wait for the requests to expire before submitting more.

## 9.5.3. Email Removals

## 9.5.3.1. Potential Attack: Lockout

## 9.5.3.1.1. Description

1
An attacker with access to a compromised user account could first add an email address under the attacker's control to the account, and then remove the user's other email accounts in order to lock them out of the account and prevent them using their email addresses for password resets.

## 9.5.3.1.2. Mitigation

1
When an attempt is made to remove an email address from an account, the idstore server sends a token to all the other addresses on the account that allows the owner of the email address to deny the removal. This serves two purposes: The user whose account was compromised is effectively notified of the compromise, and has an (albeit likely short-lived) opportunity to mitigate the damage by refusing to allow the attacker to remove the address (assuming that the user can deny the request before the attacker has the opportunity to permit it).
2
If the attacker does manage to succeed in removing the email address, the audit log allows the administrator to see the exact series of events that occurred, and manually reset the user's account password and email addresses.

## 9.5.4. Password Resets

## 9.5.4.1. Potential Attack: Spam

## 9.5.4.1.1. Description

1
An attacker with knowledge that a given email address is used by a user account in the system could request lots of password resets for that address. The intent of this attack would be to get the idstore server to send lots of mail to the email address, either to annoy the owner of the address, or to try to get the MTA associated with the server blacklisted as a sender of bulk unsolicited mail.

## 9.5.4.1.2. Mitigation

1
The idstore server currently applies configurable rate limiting for password resets, with the suggested default being one verification allowed every ten minutes. In this case, the limit is applied on a per-IP basis.
2
This will, unfortunately, have the side effect of counting towards the user account in question's email verification limit. A user may have at most 10 in-progress email verifications at any given time. Any attempt to create another email verification beyond this limit will be denied by the security policy. The user will have to either manually clear the verifications (by denying the requests from an email account under the user's control), or wait for the requests to expire before submitting more.
9.4. Admin API
Previous
9. Security
Up
Front Matter
Next
io7m | single-page | multi-page | epub | Idstore User Manual 2.0.0