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.
Related
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 want to decrease complexity of password for recovery password asp.net.for example if a user do the recovery, it send a random password only with numbers. not with complex characters!
and my second question is that can recovery password send old user password to his/her email again or not?
thank you
I would recommend setting it up so you DON't sent new passwords over mail to the user. Instead send a link to a generated URL that is valid for a specific time from which the user can set a new password. This way you get around a lot of security issues with sending passwords to users in their mail.
Sending the old password is realy bad practice and a huge security flaw in your system. Users normally reuse passwords. If anyone gets access to your database or pushes the users password recovery button your user is toost. So you have to save them as a hash with a salt. A way to let users change their password can be to send then a 1 time usable link where they can type a new password for your system.
A customer of ours complained about login password recovery using plain text password. The only workaround I know is auto-login with encripted username and passord in the query string.
What other options exist to increase the password recovery security?
Thanks.
You can send them a URL that lets them reset the password themselves.
You could create a database table that stores, at the very minimum, a user id and a hash value.
Send the user a link that includes the hash, and on the receiving page look up the associated information and allow the user to reset the password to the account. Which I'm hoping you store in the database as a hash value. Plain text passwords should never be stored or sent out.
Just be sure that the link either expires or is deactivated once the password is changed. Otherwise someone could visit that link whenever they want and change the password.
Along the same lines as Brandon's excellent answer, here is what we do:
Do not store passwords in plain text, or even a decryptable value. Always store passwords using a 1-way hashing algorithm. This means only the user can ever know what the plain-text password is.
When a user forgets their password, present them with a form where they enter their email address, and click submit.
When they submit their email address, create a table row with 2 major pieces: The first is a password reset token (we use a Guid for this). The token should be timestamped, so that you know when it was created, and when it expires (ours expire within 2 hours of submission). The second piece is a secret code that the user will have to enter in order to reset their password.
Send an email to the user, with a link to a page that will accept the token and secret code. When they click the link (or visit the page and enter the code manually), you can then present them with a page that lets them change their password without knowing its previous value.
Using a time-constrained token is a good idea, because if the user's email account is later compromised, the criminals can't use the email to reset the password -- assuming of course that the email account is not compromised within 2 hours of the password reset request.
I wouldn't send out the actual password of the account in plain text to the user's email address. The reason for this is because if someone hacked the users email address now they have their actual password. Most likely this password will be used for other systems as well.
The alternative is to send an encrypted querystring that links to that user and allow them to change their password based on some sort of security question or demographics you have specific to that user.
Facebook uses a matching of friends images to names. If you have their DOB and address you could use that (not that secure). Or you could set up specific security question and answers which would be better.
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/
This question already has an answer here:
Closed 12 years ago.
Possible Duplicate:
sending to an email with contact form asp.net
How to send email from ASP.NET page using C# as for forget password, password will be automatically emailed to the alternate id. I need how is it possible to send email from ASP.NET page using C#.
There is no shortage of articles and tutorials on this.
Side note: Being able to email the user their password implies that you're storing their password in plain text. Please, please don't do that. Passwords should be stored in an encrypted form. If the user forgets their password, email them a temporary link for them to reset their password.
You could use the SmtpClient class to send an email in a .NET application.
What you are suggesting sounds like a security risk. It is inadvisable to send a password through email, since this assumes your are storing the plain text password somewhere. Since you should only know the salted hash of the password, you probably want to make the user reset their password instead.
I suppose if you still have some reason to send an email you can check out an extensive tutorial here to start. Seriously though, You can compromise all of your users security if you are not hashing there passwords, and even more so if you are emailing them out.
The short answer is, as stated above (+1'd btw), to use the SmtpClient class.
However, it's dangerous to go emailing passwords around. As a rule of thumb:
Don't send passwords in clear text
Don't store passwords in clear text
When storing a password (if you don't have some framework that does all this for you)
Create a salt
Append the salt to the password
Hash the resulting string
Store the salt and resulting hash
Discard the password
When authenticating, add the salt to
the newly provided password, hash the
resulting string, and compare to your
stored hash
If a user has forgotten their password, send that user an email containing a one-time use, time-sensitive (expires in 1 hour?), unique-link to reset his/her password. It's also a good practice to require the user to manually provide his/her account name or other identifying criteria on the password-reset form.