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.
Related
I'm searching for a specific way to encrypt my data.
I want to encrypt it with my password and decrypt it with that.
Later I want to gain other people access to chosen parts of my data with their passwords.
Is there any other way than to decrypt the data everytime I add a new "reader" and encrypt it all again with a "mix" of all passwords?
And than the big question is how to decrypt without knowing the passwords of everyone?
And than I thought of another problem. How to validate that the given/login password is correct?
I thought the following might work without saving the actual password or the encryption password:
Get a password ; "Thats an amazingly bad password"
Use the hash as encryption and decryption key ; hash(salt + "Thats an amazingly bad password")
Save the hashed hash as validation for the password ; hash(hash(salt + "Thats an amazingly bad password"))
What do you think about it?
Thanks for help everyone
Encrypt the data once with a secure key such as random bytes.
For each user encrypt the above key using the user's password (properly extended), save that in a file or DB under the userID and a salted/hashed password for authentication.
To access lookup the user's entry verify the supplied password with the salted/hashed password, decrypt the data key with the user's password.
Decrypt the data with the data key and return to the user.
Side advantage: A user's password can be changed without changing the actual key the data is encrypted with.
For the second part:
Do not hash(hash(salt + "Thats an amazingly bad password")), use a password extension method such as PBKDF2 on the user supplied password for the encryption key. Such methods take a salt and a password and iterate many times to make the operation slow, somewhere around 100ms seems to be a good target.
Hashing a hash does not accomplish anything other than adding a trivial amount of time to the operation.
I want to encrypt user's personal data then save them in database .
the encryption must be done in application ( I can't do that in sql server side )
now I wonder if it's possible to use each user's password to encrypt and later decrypt their data ? what are pros and cons of this approach /
One big 'con': what if the user changes his/her password? Then you would need to re-encrypt all data!
You've said that you want to store secure personal data of a user. Doing this unless the personal info. is extremely sensitive is generally NOT recommended for a number of reasons. What is commonly done however is hashing + salting of the user's password.
This page has a good explanation on how hashing and salting works and why it's better than encrypting, and then decrypting the password.
http://net.tutsplus.com/tutorials/php/understanding-hash-functions-and-keeping-passwords-safe/
As for encrypting the user's personal information, just like a password we can use a custom salt + hashing algorithm that's quite simple but effective on our application to use the custom hash equivalent of the userID which is expected to be permanent, static and persistent forever.
Since the uID (or a specialized unique string for every user) can be hidden from normal public and we ensure that our custom shared function cannot be accessed from unauthorized sources, we have a solid secured system.
This means, we hash+salt personal info based on a unique string such as a userID and a hash+salt the user's password aswell. For the personal information to be decrypted, both the userID hash and password hash should match with the database.
A better approach would just be to use known encryption protocols within your program. Data sent via HTTPS TLS for example is quite secure if implemented right.
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/
What's the best way to save user credentials in flex? Local storage doesn't seem like good place for storing confidential data, because it saves information as a plain text.
You shouldn't. Use browser cookies or a session token to identify the user to the server. For instance:
User enters username and password into a form in Flex and clicks login.
Server validates credentials. Then either in memory or in a database the server associates a random (and sufficiently secure) token with the user. Then the server returns the token to the client.
Client saves the token in either a cookie, LocalSharedObject, or just in memory. Then subsequent requests also include the token.
You can use ExternalInterface to communicate with JavaScript and store data in browser cookies.
Don't store users' name or password in cookies - create a session in the server with credentials in it, and store the session id in the browser cookies.
if your service don't support credential, then the only think you can do is save user login state in SharedObject.
You can save hash value of UserName + Random Token to SharedObject and save a copy of UserName too in SharedObject, then when application created creationComplete check wheather the hash value match with the saved user name.
the good thing about this trick is:
Password never persisted locally.
Harder to fake login because need to
match username with the hash value.
a bit hard to explain here you can check it here, source code is available for download.
User credentials are normally stored in a session variable.
You don't necessarily need to save the credentials as plain text in Local Storage; in fact, Local Storage (SharedObject) is actually serialized as AMF, so it's not plain text to begin with. Whatever medium you use to store your sensitive data, you should certainly consider using some sort of hashing or encryption techniques like SHA1 or RSA.
The difference between hashing and encryption is this:
Hashing (SHA1, MD5, etc) is a one-way encryption - in other words, it's very difficult to determine the original value of the hashed value, so what you can do is compare one hashed value to another since these hashing algorithms will always spit out the same thing.
Encryption (RSA, AES, etc) is a two-way encryption - in other words, you can determine the original value of the encrypted data, usually by using a public/private key combination
It really depends on what you're trying to do.
Hope you come right
SharedObject is a very bad place to store your password in.
Please see this:
http://livedocs.adobe.com/flex/3/html/help.html?content=security2_22.html
Can users request that their password be emailed to themselves if the password is stored as a hash value?
Is there any way to convert a hash value to the clear text value with the proper information (& what information would you need)?
If a user has the same password hash value stored on two sites, would their password be the same for both sites?
If you're only storing a hash of the password, then no. ...and you should only be storing a properly-salted hash of their password, anyway.
Password reset mechanisms are the proper alternative.
Hashed passwords cannot be retrieved in general (this depends on the hashing function, secure hashes cannot be retrieved). If they have the same hash on two sites, they could have the same password, this depends on the hash salt used by the sites, what method etc.
If your password is securely stored in a good hashing system, a provider should never be able to email you your password, you must reset your password if you forget it.
In short, no. With most hashing algorithms, you can have multiple inputs with the same output. It is often better to offer a password reset option.
There are different types of hashing algorithms. Some are more secure than others. MD5 is a popular, but insecure one. The SHA-family is another more secure set of algorithms.
By definition, a hash is a one way function. It can not be reversed.
http://en.wikipedia.org/wiki/Sha-1
If there was a simple way to recover the clear-text password, there would be no point in hashing the passwords to begin with. At that point you might as well just base64 or ROT13 them. (don't do that!)
As others mentioned, use other password recovery methods. There really is never a good reason to have access to clear-text passwords.
If the hash at two sites is the same, the user most likely has the same password at both. Not 100% guaranteed however, there could be a hash collision, but that is hugely improbable.
There is no way to reverse the commonly used hashes. They can be bruteforced (trying every single possible password) or you can use a wordlist (using a list of commonly used passwords) in combination to brute force to speed it up some, but it is still a very slow and CPU intensive process.
The best way, which many sites use, it to create a "Password Reset" button where you enter your username and email, and if they match, it sends you a random password and gives you a link to the login page and you can login with your random password and change your password.
To do this you must have a model with the fields:
Hashed_password
Salt
And you need to know the method user to hash the password( Here I use SHA1)
Then you can define in your controller:
def self.encrypted_password(password, salt)
string_to_hash = password + "wibble" + salt
Digest::SHA1.hexdigest(string_to_hash)
end
Next you can compare:
user.Hashed_password == encrypted_password(password, user.salt)
True means that "password" is the password for the user "user"
The general idea behind storing a hash of a password is to ensure the passwords are secure...even from those who have access to the database. Trust is never implicit. A hash is a one-way algorithm, so there is no way to derive the original password from a hashcode. Usually, when a user needs to recover their password that was stored as a hash, you should ask them their secret question, and either email them their temporary password, or email them a temporary link where they can change their password. This ensures that the password is never stored clear text, and is secure from all prying eyes, even those who might be assumed to be trustworthy.