I am trying to push metrics towards basic auth authenticated Push Gateway. But I am running into 401 - Unauthorized
So I installed a local push gateway and configured it with basic authentication:
The password is encrypted as described here : https://github.com/prometheus/exporter-toolkit/blob/master/docs/web-configuration.md#about-bcrypt
basic_auth_users:
pushgateway: $2y$10$d6t8zGfPMZBLFLpoClFcReK6z4gxkDr2H8jnEfOaUpjpLX4.tbyTS%
In my code, I specify the username and password as follows:
this.pushGateway.setConnectionFactory(new BasicAuthHttpConnectionFactory("pushgateway","<password>"));
The password above is the one that was encrypted and put into push gateway config.
The documentation here (https://github.com/prometheus/client_java#with-basic-auth) does not mention anything about encrypting the password, the password is provided in plaintext.
Can someone please point out what am I missing?
As said in the documentation you outlined, the bcrypt procedure only applies to exporters using the exporter-toolkit while the Java client takes the parameter in plain text.
The reason behind that is that bcrypt is designed for password storage. bcrypt internally generates a salt for you and various information needed to recompute the hash from the plain text.
The information are separated by $ and salt is the 22 first char of the hash; in your example:
2y is the BCrypt algorithm version
10 is the strength of the algorithm
d6t8zGfPMZBLFLpoClFcRe is the salt
remainder is the hash
When authenticating to the exporter, basic-auth will send the password in plain text and bcrypt can be used to validate it on the server side.
If you were to send it hashed from the client, the exporter (server) would not know how to recover the plaintext password (it is a hash, not an encryption).
If the secret is leaked on the server side, the salt (supposedly) ensures that the password is hard to recover. On the client side, you are responsible for making sure the plain password is not leaked.
Related
I want to decode the encrypted value from database. I want to sent the actual password to user via mail when he gave forgot password.
The following is the code used for encoding the passowrd
BCryptPasswordEncoder passwordEncoder = new BCryptPasswordEncoder();
String password = passwordEncoder.encode(user.getPassword());
How can do the decode?
BCrypt is a password hashing function, i.e. a one-way function.
You can't decrypt a BCrypt hash just like you can't go back from chicken mcnuggets to the original chicken.
You can only verify that two BCrypt hashes are the same, thus verifying that a supplied password matches the original one.
A typical solution to this is to send a single-use password reset link to the user, use secret questions or some other information confirming user identity to let them set a new password.
It is not advisable to send the actual password to the user. you can send an activation link rather in an email.
So I'm developing my messanging app with encryption evolved using RSA. Currently I came up with this algorithm:
= Update for auth =
Screenshot:
In this case private keys are generated only from password, and server knows only password hash just to authorize users (unhashed password is never transmitted to server), therefore is unable to generate private keys or decrypt any old message. If server will fake a public key recipent will be unable to verify signature encrypted with sender's private key.
The problem is that server can fake a sender's private, public key and password when he signs up on a service or requests a password change and recipent will be unable to detect it. So, how can I verify that keys were not faked by the server?
So, how can I verify that keys were not faked by the server?
You cannot. So long as the clients only communicate with the server, there's no way for them to distinguish between a "real" remote user and one that's being MITMed or otherwise faked by the server.
I see a couple other serious potential issues here:
Sending an unsalted hash of a password over the wire (during the login process) is hardly better than sending the password in the clear. An attacker can sniff the hash off the wire to log in -- they don't need the actual password! -- and a non-iterated SHA256 is highly vulnerable to brute force attacks.
"private key from pass" (also in the login process) implies that you're using some sort of KDF to generate a private key from the user's password. This has multiple negative implications:
Users are generally pretty bad at choosing passwords. This implies that the private keys will also be weak.
If two users happen to use the same password, they will end up with the same private key.
Any user can attack the password (and hence the private key) of any other user that they've communicated with by running the KDF on candidate passwords.
There is no process specified for negotiating a symmetric encryption key. Using RSA to encrypt messages directly limits each message to the size of the key, and makes it vulnerable to numerous attacks if the data being encrypted is not both random and unique.
In the message exchange, the user sends the server two copies of every message -- one encrypted to the target user's private key, one encrypted to their own private key. In some situations, this may make it possible to recover the message.
After calling Accounts.createUser() I'd like to validate password string on the server (that it is of allowed length and so forth..).
As far as I know, meteor sends SHA256 hash to the server instead of plaintext.
So is there a way to lookup that hash and get a plaintext password on the server?
More generally: is there a way to validate a password server side?
Update
After reading on hashes (link supplied in comments) and some more research I've understood there's no way to lookup a hash, plus g I've found out that sha256 string can encode terabytes of string input, but is always 64chars in length itself.
So no need to worry about password length bytesize in DB. Good to know =)
You are not supposed to have plaintext passwords on the server. If you did that, you could technically store the password as plaintext instead of hashing it, which is a security no-no.
If you really wanted to do this (and I don't recommend it), you would have to remove the accounts-password package and roll your own (insecure) authentication.
I have a Flash/ActionScript login client that sends the password to the server. On the server, that password is checked a WordPress database. The passwords are encrypted with the WordPress encryption method.
I'm using smartfoxserver2x, which encrypts the password on the client side before it is sent to the the server to be checked against the database (WordPress-encrypted) password.
So here's the flow:
on the client, plain text password gets encrypted by sfs2x and sent to the server
on the server, sfs2x uses checkSecurePassword() to remove the sfs2x encryption and compare the plain-text password entered with the WordPress-encrypted password. They will obviously be different.
On the sfs2x forums, it was suggested that I encrypt the plain-text password with the WordPress hash before sfs2x encrypts it and sends it on the server. So I need to have 3 steps now:
on the client, plain text password gets encrypted with wordpress hash
on the client, that password gets encrypted by sfs2x
on the server, sfs2x uses checkSecurePassword() which removes the sfs2x encryption.
How can I achieve the first step?
WordPress encryption method (in php)
Sfs2x checkSecurePassword() API on the server (in Java)
My client login is in ActionScript. I am able to grab the password plain-text in ActionScript, but I don't know how to apply that WordPress encryption method (php) in ActionScript.
Would it not be more straight-forward to just store the sfs2x hash in the database, rather than the WordPress hash (albeit, I haven't worked with WordPress as of yet)?
Plus, if it initially hashes in sfs2x, what do you store in the database? The wp hash of the sfs2x hash?
I ask mainly as from what I can find, both wp and sfs2x use non-recoverable encryption methods (MD5 for both?). That, and you say the two are different. If sfs2x is hashed by wp into the database, it's that hash that wp will recognise, not the plain-text.
PS: I'm pretty new to the encryption game, so from what I've said, the issue I can see is hashing by sfs2x when the user enters the password ends up being different to hash when the user first entered their password; albeit, I'm unsure if that would occur. Again, I'm new.
Client side encrption of user password->>
I have searched for an answer to my question on this site but there is nothing specific to my question and was wondering if someone could shed some ligth.
*THE QUESTION***
Would it be possible (and secure) if I was to encript a user password on the client side by using the user entered password on the login form as the passsword for the encrpted file, then send file to server side. The only way that this file can be decypted would be with an administrative password (second password) which only the server side knows meaning that not even the user is able to decypt it.
As an example - say i encrpt a password using the user entered form password in winrar. the winrar file gets sent to the server. Now for the server to decrpt and get the password it needs to use its unique server side decypting password.
Or perhaps, instead of using the user entered password to decrypt - get say Javascript to produce a once of random() password?
I'm not that advanced in web development and only have loggic to go off and hope that somone who is can give me some pointers on the flaws of this approach?
Unless you use HTTPS and SSL, this is inherently insecure, since an attacker can pre-emptively replace your Javascript with malicious Javascript that sends the user's password to an evil server, then does everything else normally.
Using one password to encrypt and a different password to decrypt is called Public-key Cryptography (PKI)
But if you do use it, then there is no need to send the encryption key to the server as a "public" key used to encrypt the data and only a "private" key can decrypt it.
Implementing PKI in Javascript would be a big project.
You might want to re-phrase your question, it is a bit confusing.
You could store your password as a one way hash (ie MD5). Then on the client side, MD5 the password input and send that to the db..
See https://docs.djangoproject.com/en/dev/topics/signing/