Tutorial: Understanding Local Password Hashing in Access Server
Overview
Access Server stores local user passwords as secure cryptographic hashes rather than plaintext. The hashing format used depends on your Access Server version and configuration. Understanding these formats can help you troubleshoot authentication issues, verify user entries, and ensure your deployment follows current security best practices.
This tutorial explains how Access Server stores password hashes, how to identify the format you’re seeing, and what to expect when comparing hashes across versions.
Prerequisites
An installed Access Server.
Console access with the ability to get root privileges.
Access Server stores the hash of a user's password in the property:
pvt_password_digestThis value appears when querying user properties with sacli or when viewing the Access Server configuration database.
Example user properties
Connect to the console and get root privileges.
Switch to the scripts directory:
cd /usr/local/openvpn_as/scripts/Get user properties:
./sacli UserPropGetExample output:
"brandonqa": { "pvt_password_digest": "<hash value>", "type": "user_connect" }The value is never the user's actual password. It's a one-way hash created using one of several supported algorithms.
Access Server uses three main hashing formats, with each format storing the hash differently:
SHA-256.
PBKDF2 (default in Access Server 2.10.1+)
SCrypt (optional, supported in Access Server 2.11.0+)
SHA-256 format (Access Server 2.x → 2.9.x default
Example from Access Server 2.9.6:
a69e46f0bf641ec95da54e3c58116d4280ad478221fa3ae759a6b83ff28a6e3dDetails:
32 bytes (256 bits)
Hex-encoded
No salt stored with the hash
No iteration count
Characteristics:
Fast hashing algorithm.
Secure when originally implemented, but no longer recommended for password storage because modern hardware can brute-force it more easily.
PBKDF2 format (Access Server 2.10.1+ default)
Example:
$P$QHoQZ4rFNCXe/ebBogcb5A==$DAaBiGViXSecybPiUx6pq47LZ6XfNTx6fDroRleSJXw=This format consists of three components:
<$P$><salt>$<hash>Breakdown:
Prefix:
$P$Indicates PBKDF2.
Salt:
QHoQZ4rFNCXe/ebBogcb5A==Base64 encoded
32 bytes
Hash:
DAaBiGViXSecybPiUx6pq47LZ6XfNTx6fDroRleSJXw=Base64 encoded
32 bytes
Characteristics:
Uses key stretching (many iterations).
Much stronger than SHA-256 for password storage.
Default in Access Server 3.0.0 and later.
SCrypt format (Access Server 2.11.0+ optional)
Example:
$S$2Qimw8oLAgCcaZFAuLJ8RA==$7NsNN2WPDCCwd74j59sNlF1q5yW+GFFFOLVyB/WKZBc=This format consists of three components:
<$S$><salt>$<hash>Breakdown:
Prefix:
$S$Indicates SCrypt.
Salt:
2Qimw8oLAgCcaZFAuLJ8RA==Base64
16 bytes
Hash:
7NsNN2WPDCCwd74j59sNlF1q5yW+GFFFOLVyB/WKZBc=Base64
32 bytes
Characteristics:
Memory-hard algorithm.
Designed to resist GPU and ASIC brute forcing.
Most secure of the supported formats.
Access Server selects the hashing algorithm based on:
The version you're running.
Whether your installation is fresh or upgraded.
Whether you've explicitly enabled SCrypt.
3.1 Determine your version and install type
Check your Access Server version.
Determine whether your system is:
An older deployment upgraded over time (for example, started on 2.10.0 or below and later upgraded), or
A fresh install created directly on 2.10.0 or later.
3.2 How hashing behaves by version
Access Server 2.10.0 or earlier:
All local user passwords use SHA-256.
Access Server 2.10.1 or later, and the system was upgraded from 2.10.0 or earlier:
Existing users keep their SHA-256 hashes.
A user's hash is updated to PBKDF2 when that user changes their password.
If you later enable SCrypt (see next section), and are on 2.11.0 or later, a user's hash is updated to SCrypt instead when they change their password.
Access Server 2.10.1 or later, and this was a fresh install:
New local users use PBKDF2 by default.
There's no way to change them back to SHA-256.
If you are on 2.11.0 or later and enable SCrypt, users will migrate to SCrypt when their passwords are changed.
3.3 Enabling SCrypt (Access Server 2.11.0+)
If you want to use SCrypt for local passwords and you're running Access Server 2.11.0 or later, enable it with:
cd /usr/local/openvpn_as/scripts ./sacli --key "auth.local.0.prefer_scrypt" --value "true" ConfigPut ./sacli startAfter enabling SCrypt:
Existing users keep their current hash (SHA-256 or PBKDF2) until they change their password.
When a user changes their password, their
pvt_password_digestis recalculated using SCrypt.
Access Server maintains backward compatibility with older hash formats, so users aren't locked out during upgrades. Hashes are only updated when a user changes their password.
Identify whether any users were created on earlier versions of Access Server.
Local user accounts originating on 2.10.0 or earlier always created local passwords using SHA-256.
Understand how Access Server handles upgrades:
When upgrading from 2.10.0 or earlier to any new version, existing users keep their SHA-256 hashes.
Access Server does not automatically convert old hashes to newer formats.
Know when hashes are updated:
A user's password is rehashed only when they change it.
The new hash format depends on your version and configuration:
PBKDF2 becomes the new hash on password change when running 2.10.1+ (default behavior).
SCrypt becomes the new hash on password changes only when running 2.11.0 or later, and
auth.local.0.prefer_scryptis enabled.
Use this behavior to strategically:
Prevent authentication failures after upgrades by allowing existing hashes to remain valid until users naturally change their passwords.
Gradually migrate users to modern hashing algorithms (PBKDF2 or SCrypt) without forcing immediate downtime.
If you want all users to migrate to PBKDF2 or SCrypt immediately:
Require a global password reset.
Communicate the change to users to avoid disruption.