Authentication overview
Dehash.lt provides an API for developers to integrate password hashing and verification capabilities into their applications. Authentication for the Dehash.lt API relies on API keys, which serve as a primary method for client authorization. This approach ensures that only authorized applications can access and utilize the services, maintaining the integrity and security of password operations. API keys are typically sent in the Authorization header of HTTP requests as a Bearer token.
The system is designed to offer a balance between ease of integration and necessary security measures for managing sensitive password data. Developers are responsible for securely handling their API keys to prevent unauthorized access. The Dehash.lt API focuses specifically on cryptographic hashing and verification, abstracting the complexities of secure password storage methods like Argon2 or bcrypt, while the authentication mechanism protects access to these operations rather than directly authenticating end-users.
For detailed information on the specific endpoints and their authentication requirements, refer to the official Dehash.lt API reference documentation.
Supported authentication methods
Dehash.lt's API primarily supports a single authentication method: API Key authentication. This method is widely used for server-to-server communication and for applications where the client application directly interacts with the API.
The API key acts as a secret token that identifies your application and authorizes it to make requests. When a request is made to the Dehash.lt API, the API key must be included in the request headers. This key is typically generated from the user's account dashboard and should be treated as a sensitive credential.
While API keys offer a straightforward authentication mechanism, best practices dictate that they should always be transmitted over a secure connection (HTTPS/TLS) to prevent eavesdropping and unauthorized interception. The use of strong, randomly generated keys and regular rotation of these keys enhances the overall security posture.
The following table summarizes the supported authentication method:
| Method | When to Use | Security Level |
|---|---|---|
| API Key (Bearer Token) | For server-side applications and direct API integrations where the API key can be securely stored and transmitted. Suitable for programmatic access to hashing and verification services. | Moderate to High. Security depends heavily on key secrecy, secure storage, and transmission over HTTPS. Provides authentication for the calling application, not end-users. |
Other authentication methods like OAuth 2.0 or mutual TLS (mTLS) are not explicitly supported for direct API access as of the current documentation, focusing instead on the simplicity and effectiveness of API keys for its specific use case. For a broader understanding of API authentication methods, resources like OAuth.net provide comprehensive guides on various authorization flows and token types.
Getting your credentials
To access the Dehash.lt API, you need to obtain an API key. This key serves as your primary credential for authenticating requests. The process typically involves logging into your Dehash.lt account and generating a new key from the dashboard.
- Sign Up or Log In: First, navigate to the Dehash.lt homepage and either create a new account or log in to an existing one.
- Access Dashboard: Once logged in, locate your account dashboard. This is usually accessible via a link such as "Dashboard" or "My Account."
- Navigate to API Keys Section: Within the dashboard, look for a section specifically designated for API keys or developer settings. The exact path might vary but commonly includes terms like "API Access," "Credentials," or "Settings."
- Generate New API Key: Follow the instructions to generate a new API key. You might be prompted to give your key a descriptive name to help you manage multiple keys if needed (e.g., "Production App Key," "Staging Environment Key"). Ensure you copy the key immediately after generation, as it might not be shown again for security reasons.
- Store Your Key Securely: Once generated, store your API key in a secure location. Avoid hardcoding it directly into your source code, especially for public repositories. Environment variables, secret management services, or configuration files are preferred storage methods.
Dehash.lt offers a free tier that includes 5000 hashes per month, allowing developers to generate and test API keys without immediate cost. This is an excellent way to familiarize yourself with the authentication process and API functionality.
Authenticated request example
When making authenticated requests to the Dehash.lt API, your API key must be included in the Authorization HTTP header as a Bearer token. This widely adopted standard for token-based authentication is straightforward to implement across various programming languages and HTTP clients.
POST /api/v1/hash HTTP/1.1
Host: api.dehash.lt
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{
"password": "mySuperSecretPassword123"
}
Below are examples demonstrating how to include the API key in requests using popular programming languages supported by Dehash.lt through their SDKs. Replace YOUR_API_KEY with the actual key you obtained from your dashboard.
Python example
import requests
api_key = "YOUR_API_KEY"
url = "https://api.dehash.lt/api/v1/hash"
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json"
}
payload = {
"password": "mySuperSecretPassword123"
}
response = requests.post(url, headers=headers, json=payload)
if response.status_code == 200:
print("Hashed password:", response.json())
else:
print("Error:", response.status_code, response.text)
Node.js example
const axios = require('axios');
const apiKey = 'YOUR_API_KEY';
const url = 'https://api.dehash.lt/api/v1/hash';
const data = {
password: 'mySuperSecretPassword123'
};
axios.post(url, data, {
headers: {
'Authorization': `Bearer ${apiKey}`,
'Content-Type': 'application/json'
}
})
.then(response => {
console.log('Hashed password:', response.data);
})
.catch(error => {
console.log('Error:', error.response ? error.response.status : error.message, error.response ? error.response.data : '');
});
PHP example
<?php
$apiKey = 'YOUR_API_KEY';
$url = 'https://api.dehash.lt/api/v1/hash';
$data = json_encode(['password' => 'mySuperSecretPassword123']);
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, [
'Authorization: Bearer ' . $apiKey,
'Content-Type: application/json',
]);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
if ($httpCode === 200) {
echo 'Hashed password: ' . $response;
} else {
echo 'Error: ' . $httpCode . ' ' . $response;
}
curl_close($ch);
?>
These examples illustrate the fundamental pattern for authenticating requests using your Dehash.lt API key. Ensure that all API calls are made over HTTPS to encrypt the key during transmission, as recommended by general security guidelines for web APIs from sources like Mozilla Developer Network on Authorization headers.
Security best practices
Maintaining the security of your Dehash.lt API keys is critical to prevent unauthorized access to your password hashing and verification services. Adhering to established security best practices can significantly mitigate risks.
-
Secure Storage of API Keys: Never hardcode API keys directly into your application's source code, especially if the code is publicly accessible (e.g., in a public GitHub repository). Instead, store them in:
- Environment variables: A common practice for server-side applications.
- Secret management services: Solutions like AWS Secrets Manager, Google Cloud Secret Manager, or Azure Key Vault for robust key management.
- Configuration files that are excluded from version control (e.g., using
.gitignore).
-
Use HTTPS/TLS for All API Calls: Always ensure that all communication with the Dehash.lt API uses HTTPS (HTTP Secure). This encrypts the data in transit, protecting your API key and other sensitive information from eavesdropping during network transmission. Dehash.lt's API endpoints are designed to enforce HTTPS, but it is important for client applications to also enforce it.
-
Regular Key Rotation: Periodically rotate your API keys. This practice limits the window of exposure if a key is compromised. Dehash.lt's dashboard should provide functionality to generate new keys and revoke old ones. A common rotation schedule might be every 90 days, or immediately if a potential compromise is suspected.
-
Least Privilege Principle: If Dehash.lt offered different types of API keys with varying permissions (though currently it primarily offers a single type for its core functions), the principle of least privilege would dictate using keys with the minimum necessary permissions for a given application or service. This limits the damage if a key is compromised.
-
Monitor API Key Usage: Keep an eye on your API usage patterns. Unusual spikes in requests or requests from unexpected geographical locations could indicate a compromised key. Although not explicitly detailed in the Dehash.lt documentation for monitoring, general API security principles encourage this practice.
-
IP Whitelisting (if available): If Dehash.lt were to offer IP whitelisting, configure your API keys to only accept requests from a predefined list of trusted IP addresses. This adds an extra layer of security, ensuring that even if a key is stolen, it cannot be used from an unauthorized location. Consult the Dehash.lt documentation for any updates on this feature.
-
Error Handling and Logging: Implement robust error handling for API authentication failures. Log these failures (without logging the API key itself) to detect unauthorized access attempts. Excessive authentication failures might indicate a brute-force attack or key compromise.
By implementing these best practices, developers can significantly enhance the security posture of their applications integrating with Dehash.lt, protecting both their systems and the integrity of user password data.