# Barong Security Hardening

This document describes the available security options implemented in the application and advices for configuring with highlighting the main (high-risk) security options

# Password hashing

Barong since 2.0 version use OpenBSD bcrypt() password hashing algorithm, that allow us easily store a secure hash of users' passwords.

As a base Barong takes bcrypt-ruby gem - Ruby binding for the OpenBSD bcrypt() With rails 5 has_secure_password it gives us full power of algorithm.

Read more about password hashing algorithm in barong.

Read more about additional password strength and regexp configuration.

# Challenge–response test (captcha protection)

In order to prevent script attacks on API and possible brute force on session- and user- related endpoints we implement captcha protection.

Configuration manages through environment variable - BARONG_CAPTCHA. Available values - geetest, recaptcha, none. With a wrong value barong will fail on start with error: #{KEY} invalid, enabled values: NONE GEETEST RECAPTCHA.

!!NOTE: NONE is a default value, but its highly not recommended to use in production environment.

List of endpoints protected can be configured in barong.yml file, common (and the most secure) list of endpoints is:

captcha_protected_endpoints:
  - user_create
  - session_create
  - password_reset
  - email_confirmation

Captcha will be verified on SERVER side. All requests without captcha will be denied with error captcha_response.missing

More about captcha you can read here captcha policy documentation.

#CSRF protection

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data since the attacker has no way to see the response to the forged request. CSRF has become a huge deal in the recent years and it’s a part of OWASP top 10 common vulnerabilities

There are some common practices to protect your website.

First of all only POST, PUT, PATCH, DELETE and TRACE HTML requests have to be protected, since only these methods are destructive and can cause any unwanted or unauthorized damage. Therefore, every time we sent such a request we need to append a specific token to it, to verify that request is sent from a legit HTML form. The token has to be included in X-CSRF-Token (commonly used one).

This is the flow we went for:

On session creation backend sends a unique crypto-function generated token
Frontend stores that token in the DOM, typically it’s in the meta tag.
Every time a destructive request is sent to the backend, this token is appended in the header
Backend validates the header and performs the action. Error is returned if the header is invalid.
When the session is destroyed, the token is also destroyed and can’t be used again.

This approach is called a per-session token method.

For further information check the links down below:

To protect those users who don't have OTP enabled from brute-force login attacks we use rack-attack gem.

By default Barong have protection of identity/sessions endpoint, which throttle POST requests to this endpoint by both IP address and email. Limit of requests per 60 seconds can be configured by changing of barong_rack_attack_limit env (default value is 5). If limit exceeded then user will receive 429 repsonse and will be able to successfully retry when 60 seconds will have passed from the first attempt.

In test or development environment rack-attack protection is disabled unless BARONG_ENABLE_RACK_ATTACK env is set to true.

Additional settings can be configured in the config/initializers/rack-attack.rb file. To get more information about possible settings check Rack-Attack official documentation

# Barong Security Hardening

# Password hashing

# Challenge–response test (captcha protection)

#CSRF protection

#Sign in brute force protection