I am trying to use a DigestAuthenticator to secure some parts of an API I am creating using Restlet. In all of the examples, the DigestAuthenticator expects to wrap a LocalVerifier that will return the local secret in plain text. Obviously, I do not want to store all of my users' passwords in plain text. How can I use HTTP Digest with Restlet while not providing the local secret in plain text?
I have written a LocalVerifier that uses the identifer to query a db and retrieve a sha1'd password, but it doesn't work unless my Verifier returns the password in plain text.
Any ideas?
So basically I hashed all the passwords on the server side in the database, and I hashed the password on the client side before it was hashed by http digest. Seems like a more secure solution to me anyway.
Related
The ArangoDB docs discuss a couple nonce functions here:
https://docs.arangodb.com/3.1/Manual/Appendix/JavaScriptModules/Crypto.html
I understand the idea that I would create a nonce, send it to the client, hash a password with the nonce and send it to the server. But I don't really understand how these two functions work together to make this all happen.
Can someone elaborate on this documentation and the process? If I hash the nonce and the password together, how do I compare it to the stored password that's already hashed? Just looking for some guidance on the process. Thanks!
Update with more details:
I'm working on auth code. I guess in general I'm trying to understand the two functions in the ArangoDB crypto library and how they work together. The documentation doesn't elaborate very much. I found this workflow on wikipedia:https://en.wikipedia.org/wiki/Cryptographic_nonce But I'm not sure I understand it.
Client login page requests a nonce from server. Server provides. Does the server then store this nonce is the users session for later retrieval?
Client hashes password with nonce from server and a client created nonce as well and sends the username, client nonce, and encrypted password to the server.
How does the server compare the password hashed with the nonce & client nonce, to the already hashed and stored password in the database? Instead of hashing the password with the nonce & cnonce, should it just be encrypted using one of the nonce's as a key?
The ArangoDB crypto library provides two functions createNonce, which is obvious, but then it provides checkAndMarkNonce. How does this fit into the workflow? How can I check the returned nonce unless I store it in a session var? And how can I check the nonce if it's hashed along with the password? Is this wikipedia example just wrong, or am I missing some key components?
I'm currently making some research on the WSSE protocol to secure my api.
I've understood the basis and it is clear in my head.
However I face to a problem.
Let's say I want to generate a ONE-time Digest, I've to concatenate the timestamp, the nonce and the secret password.
However, on the server side, I don't have the clear password stored in database, so I'm unable to check for the digest.
Switching to clear password is not an option.
I can't either provide to the client-side the algorithm used to hash password, because they use salt, and the salt is not available to the client.
The only solution I can think about is to don't hash the Digest, just concatenate the data and base64 them.
That way I'll be able to encode the user password to check for its validity.
As password is transmited in plain text it may not be secure, but what if I force HTTPS to authenticate?
Will it be safe?
As password is transmited in plain text it may not be secure, but what if I force HTTPS to authenticate?
Will it be safe?
Yes, and within normal limits, it is the only way to get it secured.
Just send the full password, but send it over a well secured TLS connection. You can use a secure key derivation function such as brypt or PBKDF2 and input the stored random salt (one per user) and password to retrieve the "hash", which can then be checked to the one stored in the database.
Note that you don't need to send a time stamp from the client. It is of course a good idea to log & limit the number of authentication attempts though. You cannot use a time stamp as input to a hash, the outcome would be different each time the time stamp changes.
I'm using django.contrib.auth.hashers.make_password method to store passwords. There is an iOS app that sends username and password to my django site to get authenticated. I want them to send encrypted password not the raw password. But I don't know how django encrypt the password? How someone else in other platform can generate the same encrypted password?
Django has a variety of methods it can use to encrypt passwords. By default is uses PBKDF2.
You can look at your PASSWORD_HASHERS list to see what is set:
PASSWORD_HASHERS = (
'django.contrib.auth.hashers.PBKDF2PasswordHasher',
'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
'django.contrib.auth.hashers.BCryptPasswordHasher',
'django.contrib.auth.hashers.SHA1PasswordHasher',
'django.contrib.auth.hashers.MD5PasswordHasher',
'django.contrib.auth.hashers.CryptPasswordHasher',
)
Here is a SO article on implementing that algorithm in iOS:
PBKDF2 using CommonCrypto on iOS
The challenge will be that the password is salted. If you don't know the salt, you can't hash the password correctly. So you'll need to send the salt securely to the device, so your output hash matches.
version <1.4 is SHA1, >=1.4 is PBKDF2, check the table
select * from auth_user;
to make sure, the password column is algorithm$hash
check document for details.
I am making a program like yelp. Some people have some accounts. So I got to send the password to the web.
Should I encrypt the password before sending it?
After that what would be the standard password policy others used?
Should the encrypted password be the one stored on the mySQL serve? In other word, there is absolutely no need for decryption?
Basically it's like What encryption procedure I must use to send encrypted 'email' and 'password' values over the HTTP protocoll? but for objective-c
After the user logged in, my program need to tell the server that the user is authenticated already. Does my program need to keep sending password?
There are more than one architecture you can implement, and you have to choose considering many factors, like performance, how many users, server architecture...
Basically, you must use https and not http, store hashed password (MD5, SHA, ecc.) and always check if hashed password is equal to stored hashed password.
You can implement also a "session" using token (you have to create a kind of API server side and then use it on client side) or pass username and password in each call to web service (web service must verify credentials every time is called).
Another "fast" (it's not so fast anyway) solution is to implement (both server-client) a standard protocol like (it's my favorite) oAuth 2. It's used by twitter and Facebook, you can learn more here: http://oauth.net/2/
You might be looking for Base64 encoding:
http://cocoawithlove.com/2009/06/base64-encoding-options-on-mac-and.html
When sending passwords via UTF-8 encoded socket transfer, is it considered to be secure if I hash the password using either MD5 or SHA-1 prior to sending out the data? Keep in mind that I plan to compare the hashed password in a SQL database. I am worried that someone could be able to sniff the hashed password in UTF-8 then decrypt the UTF-8 encoding and could obtain my hashed password which could potentially be used to match the password in my database.
If the client just sends the hashed password, then the hashed password is the "password": a sequence of bytes which the client just needs to show to be authenticated. If the attacker can sniff that then your protocol is doomed.
If the authentication protocol consists in just presenting a piece of secret data (call it a password if you wish), then the exchange should occur within a transport medium which ensures confidentiality (so that the secret data cannot be sniffed) and server authentication (so that an attacker may not mimic a server and convince a client to send him the secret data). This is what you get out of a classic SSL/TLS tunnel (a https:// URL, in a Web context).
If you cannot establish a SSL/TLS tunnel with server authentication (i.e. the server has a certificate which the client can verify), then you may want to resort to an authentication protocol with a challenge: the server sends a sequence of random bytes (the challenge) and the client responds with a hash value computed over the concatenation of the password and the challenge. Do not try this at home! It is very difficult to do it right, especially when the attacker can intercept communications (active attacks).
A more generic answer is password-authenticated key exchange protocols. PAKE combines a cryptographic key agreement protocol (such as Diffie-Hellman) and mutual password authentication between client and server, in a way which defeats both passive and active attackers, even with relatively weak passwords (the attacker cannot get enough data to "try" passwords without interacting with either the client or the server for each guess). Unfortunately, few PAKE algorithms have been standardized beyond mathematical description, and the area is a patent minefield.
Well, if someone can sniff hash - he can fake authorization request and send the hash he already know.
Making up secure system is not easy, you would need to do authorization using asymmetric cryptography with properly signed keys to make it secure.
At least add ~100byte random salt, and use SHA1 - this way it would be way harder to bruteforce.
They could brute-force your passwords if they know the hashing algorithm. The simple (and not perfectly secure) solution is to use a challenge/response instead, the server issues a random string ("nonce") to be hashed along with the password hash. This makes your app invulnerable to the kind of replay attacks you're describing.
For more information, see HTTP's digest access authentication
Hm, if you are talking about 'proper' hashing, that means that it will 'encrypt' your password so it won't be decrypt-able, because hashing is one way function, and to decrypt it - it till take some time, and some kind of great CPU power.
If you are concerned at password sniffers, you can take it to the next level - use PRIVATE/PUBLIC key encryption. Server should send a challenge to the client (public key for encryption), client encrypts with it, and only server know how to decrypt it. For same amount of bits, it offers more protection - ie. more muscle is needed to brute force crack it.
Check this out.
How do you check the password on the database side?
If you store the unsalted hash of the password and just compare it to the input, then the hashed password can be sniffed and reused.
It's exactly as if you were storing the password itself in the database in plain text.
If you are afraid of sniffing, use a challenge-response protocol to authenticate, but in this case the secret will be stored in the database (and will be known to anyone who has access to the database).
Alternatively, you can send a password in plain text over a protected channel (SSL), but you will have to install a certificate which will most probably cost you some money (if you are using an authority from a vendor-provided list, i. e. one your customers' browsers won't complain about)