I have a very simple password box bind to a property. When user edit existing password, it displays as "......." we all know. The code is:
#Html.PasswordFor(m => m.Password, new { value = Model.Password })
However if you righ click and 'view page source', you will see the password in plain text, which seems cause security concern. Is there anyway to hide that? Thanks a lot!
There is pretty mush anything that you can do about it. Since it is a user input it's value has to be specified in some way before the form submit. Client side encryption/ decryption most probably won't work since client side code can not actually be secured. So if you use client side encryption (either symmetric or asymmetric) the hacker that has an access to the page source will be either able to see the encryption/decryption algorithm or to replace the password value to something he knows. So as I said if the hacker has an access to the view source of the page while user types a password there is nothing you can do. Even PCI compliant applications that send sensitive data over the web (for example credit card numbers) send the raw user input to some remote secure tokenization server that generates a token that will be used in subsequent requests.The major thing that Html.PasswordFor does it that is instead of displaying the password as flat string it masks if so if somebody behind your back looks on the display while you are typing the password he won't be able to see it. What you must do when submitting a password is to use https in order to prevent a man in the middle attack. And of course you should not store plain user passwords on the server (only their hash values) so they could not be leaked.
Well when you are binding the view with your model and setting the value from controller.
and it simply renders the html with all its values. That's the value of password is visible. #HTML.PasswordFor simply renders the password to the browser. You need to use encryption/decryption to save and retrieve the password to make sure it will be safe.
Related
If you have an ASP.NET MVC 5 site configured without email confirmation, how can a password reset be performed by an administrator?
I can write a console app which resets the password in the database, but that seems inefficient. Also, the old aspnet_Membership_ResetPassword sproc has no counterpart in the new identity system.
I'm not sure I understand what you're trying to achieve. You still have to get the password to the user somehow, so will you be emailing them a generated password instead of the standard "follow a link in a email to a page that lets you pick a new password" approach?
Also, are you talking about specifically resetting one user's password or resetting all user passwords. If the latter, then a console app is the way to go. If the former, you can simply add a view to some backend that's only accessible to admins that let's them perform this function for a specific user.
As far as generating some random password goes, you're on your own there, but a simple web search should turn up plenty of methods to choose from.
Word to the wise, though, the email confirmation approach is standard for a reason. It provides a relatively secure way to allow a user to regain access to their account when they can't remember their password. It's most important feature, though, is that it forces the user to actually change their password, whereas with a provided password, random or not, users will actually use that password, rather than take the time to manually change it after logging in - especially with password managers these days. That means if you sent that password via email, or wrote it on a sticky or whatever, you now have a huge gaping security hole.
I am creating an app and a website for a project I've got going, but I'm not sure what I should do about login. This is not a "I'm a noob and I want an app with login"-question. I am somewhat experienced with both web-, database- and app-development, but I've never actually touched the subject of security before other than by application templates.
What I'm imagining is a 'simple' login-system like Skype, Facebook, NetFlix, really any app that you are able to log in to, which also has a website to log in to.
A part of my question is towards the security of the process. My initial thought is that a password in clean text should never be sent over internet, which makes me believe that the passwords should be hashed/encrypted on the phone, as well on the website, when logging in. I've done some small-time hashing/encrypting before, but just by using sha1 and md5 to "convert" the text. What's the proper way to do this? With my current knowledge, I assume that if I'm using md5 to encrypt a password, anyone could decrypt it with md5 too, but that I could use a SALT(?) or some form for altering key. Is that how the "big boys" are doing it, or is there a secret passage I don't know of?
Now onto the real question.. How should I store a login securely?
What I've tried: When making a "test-project" in Xcode for this, I simply created a class User with a field for username. When "logging in" by entering a username and password, I simply sent a POST-method HTTP-request to my .php-page, which simply performed a SELECT * FROM User WHERE Username = '$_POST['username']' AND Password = '$_POST['password']'; If the database returned one row, then the password was correct, and the page could print out the user in JSON or whatever. When the device got the successful login, I converted the user-object in the app, now containing the username (and potentially UserID, E-mail, Address etc.) to NSData*, and using NSKeyedArchiver and NSKeyedUnarchiver to save and load the user, never to authenticate again. If the user clicks "Log out", I wipe this 'archive'. This works, but I sense that it's not a particularly secure way of doing it. If so, why exactly is that?
(Our back-end is currently Google's App Engine(java), which has support for OAuth. Some are recommending this, but we can't find any proper documentation that makes sense for our plan with custom users)
Password Transmission
The easy way to secure this is to just send passwords over SSL. If you set up an SSL certificate and do all your authentication over https, all the back-and-forth communication is encrypted by the transport layer. Note - md5 is not an encryption algorithm, it's a weak hashing algorithm - don't use it for security.
Storing Logins
Your passwords should be stored in the database as a salted hash (random salt, with a collision-resistant hash function such as SHA256). Don't store the plaintext version of the password anywhere. If you're using PHP on the server side, you can use the new password_hash() function or crypt() to generate and compare your salted hashes.
If you're communicating securely over SSL, you should be able to just use the session capabilities of your web server to keep track of logins (e.g., $_SESSION['user_id'] = ...).
If you want to securely store your username/email/address, or anything else for that matter, the built-in keychain is the only Apple-happy way to go.
Have a look at SSKeychain (or PDKeychain or UICKeychain) and extend it to include each property you'd like to store. Generally it's used to store username and password combinations, but can be extended to store arbitrary data safely.
As for passing secure data to your server, do it over HTTPS.
I can provide examples if you'd like.
Another option is to add some sort of OAuth or XAuth login process.
That way, you are not storing any passwords, but only so called "Tokens". The tokens expire, and can be revoked.
Not storing the username and password at all is the best way to secure them.
Alex
I have an ASP.NET MVC 3 application in which I want to set
requestValidationMode="4.0"
and all areas of the website were a normal user has access have
ValidateInput(true)
SoI basically html encode all user input and save it encoded in the database. (The site is not meant to work without javascript)
My question is
How should I treat the signup, log in and change password functionality ?
Obviously I want to allow the user to insert whichever password he/she wants so,
Is it ok if for the password field I do html encode on the client and then html decode on the server, before saving the password in the database ?
Thank you
Given that passwords aren't ever likely to be displayed in cleartext (or even stored), XSS shouldn't be a concern for passwords.
You can decorate the password property(ies) of your (view) model with [AllowHtml]
I can't think of a reason why the password would need to be echoed back to the client from the server, so the Html sanitization step shouldn't be necessary? (Do password rules validation on the client)
Troy Hunt discusses this here.
I need to decrypt the password to send in email. Can anyone please guide me that how I can decrypt the "Spring Security" password in grails?
Thanks
Smac
Passwords aren't encrypted, implying that they can be decrypted, they're hashed. Hashing takes various inputs and generates a fixed-length output, so the process is lossy since a large original input cannot be stored completely within a small hash output.
But that's ok for passwords. Rather than decrypting (or "de-hashing") the stored password to see if a login attempt is valid, you hash the password from the login page and compare it to the stored hash value. These two don't have to be the same, and for example when using Bcrypt they won't be the same value, but the hash algorithm implementation will have logic to determine if two hashes are equivalent.
If you store passwords in a way that the original value can be retrieved, you might as well store them in cleartext. But that's crazy since then anyone with access to that table can see them.
As was mentioned in the comments, never send cleartext passwords by email. Instead configure a workflow where your users can reset their password. The http://grails.org/plugin/spring-security-ui plugin has this as a feature. If you don't want to use the whole plugin, feel free to steal the code for this feature. Basically the workflow is that a user requests a reset email for their username. Only ask for username, but not their email; use the one you already have. Generate a unique token and store it, and use it in the link in the email. When the user clicks the link you can validate the token and know that it wasn't just any arbitrary request from a hacker, but that it's from the user since you use their email address to verify their identity.
1) You should be using one way hashing algorithm for encrypting password Which can't be decrypted back. (Otherwise, its security threat for the application)
2) Text password should never be sent in emails. Infact, you should use workflow like sending the reset/forgot password link in the email.(The links can have UUId appended as a parameter for any new reset/forgot password request which is enough to identify).
How does one protect against XSRF attacks in Grails. I see that forms support the notion of useToken which (I think should suffice). However, remoteForm or other AJAX related request don't support this feature.
Also, is there a way to invert the functionality of useToken so that it is always used rather than enabled on a case by case basis?
You could try looking at the source code of the <g:form> tag. It uses a SynchronizerToken to create a token and store it in the session. Based on the resolution of this issue it should be possible to use the same token for all forms on the same page. I did not try this, but theoretically you would just need to manually create a hidden field on the form and generate the token in that field.
We have inject a hidden value to the request object in a before filter and encrypt the value with a specific key. We then inject that request.token value to every form on the site and when we receive a POST we have a before filter to verify that that hidden field is present and its value can be decoded by that same secret key.
If that hidden value is not present or if it is stale -- we use a timestamp as payload -- we give the client an error status.
This is an alternative way to what was described above and we use this, because we do not use sessions on our sites to make it easier to load balance.