I am facing issue while creating/updating password in grails 3.x.x Application. Whenever i try to enter any special case lets say "#" it encodes only this special character in password field.
Password value is coming from request body.
Example:
Real password : abc#555
Auto Encoded password : abc%40555
Grails by default uses a plugin that uses bcrypt algorithm to hash passwords for security.There are some configurable password hashing attributes. You can customize the password plugin with the grails.plugin.springsecurity.password.algorithm attribute.
This is in the view
<g:passwordField name="password" required="" value="${usuarioInstance?.password}"/>
This would be a part of the controller
pass = params.password.encodeAsSHA1()
This will be returned into the view again
${pass.password}
the ${pass.password} needs to change to text or decode the SHA1()
My advice:
don't use sha-1, it's insecure
don't unencrypt a password and display it in a form field. Make the user type it in if they want to change it, if they haven't entered anything then don't update that property
use spring security which by default manages all the headaches of web security and uses Bcrypt out of the box.
Security is something every dev needs to take seriously and if the client insists on unsecure practices then they need to be educated.
Edit: #zaph makes a good point below so I should add it - don't encrypt passwords. A password should never be able to be translated back into plain text. Always hash (and salt) them and compare the user input hash to the stored hash. If you choose not to use Spring Security, you can use Bcrypt standalone and use the static Bcrypt.checkpw(userInputPw, hashedPw) method to check it.
Final Edit: To avoid any confusion (since #zaph seems confused in the comments) my recommendation is to use Bcrypt - specifically, use Spring Security.
I have a very unique situation. I am building an application where a user uploads a QR code to my site, and when decoded, it has a matching ID already stored in the DB (as in I already have a record of the qr code before the user uploads it)
When they upload it, I decode it, which is a base64 string like so 6BbW0pxO0YENxn38HMUbcQ==
Like I said, That code corresponds to some information, and after they upload the QR image, I redirect them to one more page, which shows them the qr code, the corresponding information stored in the DB, and they are also prompted with a submit button. When pressed, I take note that they have confirmed, and I do some other things.
To elaborate
As a user I go to www.url.com/code/upload and upload an image. I am then redirected to /code/new with the page displaying the data stored in the DB from the correspond decoding of the image.
How can I make the submit button on /code/new reliable? Here are the solutions I can think of, and their vulnerabilities
Propagate /code/new with the correspond data stored in the DB, lets say #username and #movie into a form, with a submit button and POST the data to the server
This is dangerous because I don't think anything stops someone from editing the DOM and changing #username and #movie to something else
Pass the unique base64 identifier in the parameters such like, /code/new?id=STRING
Then when you submit, the string gets passed to the handling controller action, but i feel that this is not safe because then users can attempt to guess the strings and make concurrent post requests.
Essentially, I have a user upload a qr code, and after submission, I need to verify to verify that they were the one that uploaded the image. I lose all state, and information after they upload the image.
A proposed solution:
After the user uploads the image, create a unique string and store it in the session and also a record in the database (A user is logged in, so its the current_user.session_token), then when the user clicks submit on /uploads/new, I grab the session token, and verify that the current_user.session_token == session_token.
At this point, I can only verify that the current user was the one that uploaded the image.. I then need to somehow grab the base64 string that was from the uploaded QR code.
Another proposed solution: I temporarily put the base64 string as an attribute of the user when they upload the file. So I will have current_user.session_token and current_user.base64_string. Then when the user clicks on the 2nd submit button, I do something like
#check if the user's token is equal to the sessions, and the string is not nil
if current_user.session_token == session_token && !current_user.base64_string.nil?
data = current_user.base64_string
#hooray! I have the QR code
end
Then delete the session token, and then delete the current_user's base64_string and session_token
if a malicious user attempts to forge their session token, it won't match their's store in the database, then when I handle the post request, I will not proceed. But If a legitimate user makes the second post request, the session Id matches, and I am able to grab the base64 string.
TL;DR, I need 2 concurrent post requests that carry the information without losing it, and can verify that both the first and second post requests were done by the same user.
If anyone had the patience to read through that, I appreciate it! if there are any suggestions I would greatly appreciate it, or if you think my solution is sufficient or not, please let me know. Thanks!
Sign the parameters generated from the first request, and verify the signature when you process the second request.
The technology to use for this is HMAC. Here's how to use one version available in Ruby:
require 'openssl'
secret = 'ABCDEFGHIJKLMNOP'
data = 'user:code'
signature = OpenSSL::HMAC.hexdigest( 'sha256', secret, data )
p signature
Output:
"bd7194c0604902d6594694d25e7f27bdc2d10926638e0ce8bdda3f6debb37f6a"
This is how you can use it to link two HTTP routes together so that the second one can trust that parameters sent to it via the first one have not been tampered with:
When the first route is called, generate or fetch a secret. It is important that this secret value is not ever sent or exposed to the end user. It can simply be application configuration (which then applies to all linked requests), but if you can store it associated with perhaps the QR code, then the strongest protection is to generate a long random string just before creating the signature, and to store it ready to use to confirm the second step. Something like SecureRandom.hex is great for a short-term secret if you have somewhere server-side to store it.
Combine all the parameters on the form that you want to be tamper-free into one long message. Easiest thing to do is .join them in an array, and you should use a delimiter that is not allowed in any value, and that you are also not accepting due to validation. This string is the value to use for data in the example.
Generate the form that calls the second route. In addition to the params you want to accept at next stage, add the signature value generated as above. Do not send the value of secret to the client by putting in the form or cookie etc.
When you receive the request from the second route to finalise the multi-stage request, generate the signature from the user-sent params (after validating them), and compare with the one sent to you from the form. If it is the same, then the request is valid. If it is different then the data may have been tampered (provided you have no bugs - do check things such as consistent character encoding if any param can contain non-ASCII characters)
Provided you have kept the secret truly secret from the end user, they have next to no chance of generating a correct signature. Only your code in routes one and two knows how to do it (because it has access to correct secret, not because of any special fact on how it is written). Therefore you can trust that the values have not been modified.
I'm trying to write a simple ASP.Net app that allows the users to log in with their username and password. I'm using an EF database in the .NET Framework 4, coding in C#. My problem is, when the user registers their details on the registration page, their password value does not save. That textfield is a password field.
How can I save the passwords actual value in the database, but keep the textfield as password? Would I need to encrypt it? I've never done encryption, so any help would be appreciated. Thanks
You should use some cryptographic algorithm to compute the hash for password string (see Hash string in c#). Then store it as byte array or encoded string (like hex or base64) in db.
Facebook sends email notifications when a new message has arrived in a facebook message thread. The email allows you to reply on it without going to Facebook.
I think it is being done by Facebook by generating a reply to email address that is linked to the message thread.
Example of such a reply-to email adress of a facebook email notification (I modified some characters, so it won't work):
m+51r6w8e000000bu1jfpbziio6jmfnvvtkaevxrgojnel8qv#reply.facebook.com
I'm trying to implement a similar feature in my rails app.
I'm still a newbie in rails and wondering how I should approach this issue.
I was trying to encrypt the id of my message thread using the encryptor gem, then using this as an email adress in the form: encryptedId#mydomain.com. Issue is that the encrypted output contains characters that are not allowed in an email address.
As I know little about encryption I googled and found the possibility to base64 encode the encrypted output. This is common practice for urls. But still, this has characters (for example %) that are not allowed in an email adress.
I found that RC4 should be an encrytpion algorythm that has hexadecimal output. But the encryptor gem gives me 1 non-hexadecimal character when using this algorythm, so it doesn't seem to work. Conclusion: I'm a bit stuck.
Maybe I'm looking to far. Are there other appoaches that I could consider?
EDIT: extra info: I'm trying to make the email address non-guessable.
Thanks!
If you are trying to keep your response email addresses non-predictable, you can create your email address out of a concatenation of:
some unique aspect of the message thread such as a row ID
a similar unique attribute of the user being sent the email
a MD5 encoded hash of both of those items plus a unique string known only by your system
a random salt to the MD5
So if user 7812 posts in thread 8299 you could make your base string
u7812t8299
then take that string "u7812t8299" plus the time the email was sent (say 12:31), and a string known to your system like "purpleumbrella"
Your result string is "u7812t82991231purpleumbrella". Using:
Digest::MD5.hexdigest("u7812t82991231purpleumbrella")
we get an MD5 hash of:
5822aceca1f70afdb06f53b5c7e4df99
now send the user an e-mail with a return address of
u7812t8299-1231-5822aceca1f70afdb06f53b5c7e4df99#yoursite
When you get an e-mail back to that address, your system will know that it's for user 7812 posting in thread 8299, and because only your system knows the password required to create the MD5 sum for this combination that would result in an MD5 string starting with 5822aceca1, you can verify to a certain extent that this is not a randomly generated email by someone trying to spam your system.