If use Accounts.changePassword(oldPassword, newPassword, [callback]), user can change his password to anything he wants in browser console because this function is executed in client side. (And how can I disable it??)
If use Accounts.setPassword(userId, newPassword, [options]), I have to send the old-password and new-password to server, how can I avoid send it in plain text, to secure the password?
Old and new passwords are NOT sent plain text over the wire, it states so in the manual. The passwords are encoded client-side and sent over the wire encrypted.
changePassword() however comes with the accounts-password package and doesn't provide a callback on the server, nor does it allow a configuration setting for preventing password changes. If you don't want that to be available on the client, don't install accounts-password and roll your own package. I wonder however why you would want to do that.
Related
I'm building an API for WordPress on the website.
Part of the API is, of course, signing up and logging in.
I'm aware that WordPress uses a modified version of MD5 to generate the password. But that only implies if I sent a plain text password which I don't want to.
Is there anyway to hash the password on the client side, then send it to WordPress, and use the hashed password to login/signup?
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 am creating an admin interface and the admin needs the ability to create user accounts, pick and change the password.
If I try to call Account.createUser on the Client, it automatically logs the user in as the new user, which is what I do not want.
An approach that will work but I am afraid might be insecure is:
Call a server side Meteor method with the username and password for the new account that the admin has picked.
On the server I can use Accounts.createUser to create the new user with password and it will return the new UserId.
But with this approach I am sending the password in plain text over the wire. We could use https and ssl and I think we will be safe, but is there a more secure way to do this?
A much better practice which avoids any user knowing any other user's password is to create the account on the server (as you suggested) but don't specify a password, instead let the user pick it later. From the docs
Call createUser with the email option and then call
Accounts.sendEnrollmentEmail. This will send the user an email with
a link to set their initial password.
How can I check at least the password length from the server submitted by the client?
I know that password is not sent plain over the wire and thus I'm wondering on how to?
Password data is only communicated through hashes so, as you mentioned, the server never sees the user's password during a key exchange. The server can create the user with a password but that string would have to be transmitted somehow.
Your best bet is to have the length checked in your signup form. I realize client code can't be trusted, however it seems unlikely that a motivated hacker is going to modify the source just to have a weak password.
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/