io7m | single-page | multi-page | epub | Idstore User Manual 1.0.0-rc0005
9.2. Security
Previous
9. Security
Up
9.4. Admin API
Next

# 9.3. General

- 9.3.1. Potential Attack: API Resource Exhaustion
  - 9.3.1.1. Description
  - 9.3.1.2. Mitigation
- 9.3.2. Potential Attack: Offline Brute Force
  - 9.3.2.1. Description
  - 9.3.2.2. Mitigation

## 9.3.1. Potential Attack: API Resource Exhaustion

## 9.3.1.1. Description

1
An attacker with access to the APIs could send specially crafted messages designed to exhaust server resources during parsing/validation of the messages.

## 9.3.1.2. Mitigation

1
All APIs exposed by the idstore server are defined using the Cedarbridge protocol. Cedarbridge-based protocols have the following properties:

### 9.3.1.2.2. Cedarbridge Properties

- Parsing and validation complexity is linear in the size of the parsed message. It is not possible to specify a message that will result in an exponentially complex parse. Additionally, the server currently places hard limits on message sizes from clients; 1048576 octets for commands, and 1024 octets for login requests.
- Cedarbridge protocols are very strongly-typed, operate under a closed-world assumption, and are immune to any kind of reflection-based deserialization vulnerabilities. Deserialization of messages cannot under any circumstances result in the deserialization of arbitrary objects.
- Cedarbridge protocols have a structure that is known ahead of time by both peers. Neither side gets to decide the structure of messages during communication. This is a common source of vulnerabilities in other protocols, where message types are self-describing on the wire and therefore a hostile client is able to transmit the description of a message that will cause the server to do an unbounded amount of work to parse and/or validate the message.
- Parsing code generated by the Cedarbridge compiler does not preallocate any structures. It is not possible, therefore, for a specially-crafted message to result in the server performing a huge allocation based on an attacker-provided size value. If a message claims to provide a string that is 4294967295 octets long, the parser will attempt to consume 4294967295 octets one at a time. This requires an attacker to actually provide 4294967295 octets over the network, and the attacker will run into a hard request size limit before this completes.

## 9.3.2. Potential Attack: Offline Brute Force

## 9.3.2.1. Description

1
An attacker managing to compromise the database of the idstore server will have access to the hashed passwords of all users.

## 9.3.2.2. Mitigation

1
The idstore server currently hashes all user passwords using PBKDF2 with a SHA-256 HMAC, with a default configuration of 100000 rounds and a NIST-recommended size of 16 bytes for salt values. This combination of algorithm and parameters is, at the time of writing, expected to be expensive enough to break to deter most attackers. The system never stores plain text passwords in any form, and all plain-text-carrying data types are carefully defined in a manner that prevents the possibility of plain-text passwords accidentally leaking into log files as they move through the system.
2
The algorithm and parameters used are stored per-password and can therefore be upgraded on a per-password basis as stronger algorithms are standardized and become available in Java.
9.2. Security
Previous
9. Security
Up
9.4. Admin API
Next
io7m | single-page | multi-page | epub | Idstore User Manual 1.0.0-rc0005