I'm curious what, if any precautions I should take to protect the site key. The docs mention the secret key which is used for server-side validation should be considered secret. I'm guessing site key is not sensitive but I really want to make sure.
Related
Some people are using this data validation pattern to protect forms:
A youtube video from Google for Education uses this pattern.
A similar scenario to mine with a similarly proposed solution.
Since Google for Education showcases this pattern, I want to believe it is reasonably secure. But I also understand the above solution is client-side validation, based on this answer.
Logically, doesn't this imply the validation values and logic can be exposed by scraping/viewing the source? How safe is it to store passwords and unique IDs as a regex in these validation fields?
For context, I'm hoping to use Google Forms + GAS for verified, unique form submissions from a set of non-google account emails while reducing quota usage from spam/misuse.
It's not secure. All client side validations are insecure by design. Pattern validation passwords are visible in the source code. Having said that, a single password for multiple users is also insecure. All it takes is one user compromise to invalidate the whole thing.
If you need a fully secure solution, create your own form with HtmlService with oauth authorization and Google identity.
I want to show the password from database which is encrypted.
How to show envrypted password in admin dashboard page?
I have seen laravel documentation fo rehashing but i am not understanding it
Laravel hashes passwords, which is irreversible. You pretty much can't ever see a password once it's been hashed and stored in the database, and this is by design. It isn't encrypted, and thus, cannot be decrypted.
When someone signs in to the application, their password is HASHED, and then compared with the hash in the database. This is done so that a password can not be stolen from the database.
Now, I don't know your application or your circumstances, but I would consider it very bad practice to allow even an admin access to users' passwords (there shouldn't be a reason in the world they need to see those).
Here's a great video on the matter.
But if you REALLY still need this to happen, consider a making a custom authentication driver that at least uses encryption instead of hashing (but again, probably a bad idea). I found a few different tutorials with a quick google search.
We have merchants logged in to a system, from which we want to link them to our Magento instance with some kind of admin token that will log them in directly without them having to manually login.
I see the rp_token field in the admin_user table but that appears to be related to a password reset, which probably isn't what we want.
Have done a bit of searching, found this thread which is related but is dealing with secret keys specifically (which will probably be my second challenge to resolve after resolving this one).
I'm guessing this isn't supported in core, but maybe there's a good extension out there to do it?
Or if not, what would be the best approach to implement? I'm guessing there is probably an event I could hook to look at a GET or POST param (which maybe could be a hash of the username and hashed password), then bypass the normal login() method which relies on username and plain text password.
That feels like it could be a little risky though? Any thoughts?
That feels like it could be a little risky though? Any thoughts?
This is extremely risky, but it can be done safely. I can speak on a similar issue I had in developing QuarkBar, an administration bar for Magento that is set to release this weekend.
So to show the bar, I need to verify the admin is logged in. Unfortunately that's hard to do on the frontend module, since there are two separate sessions. So to get around that I've created a quarkbar_session table. I use OpenSSL to store a secure crypt key once an admin is logged in, that I then check for on each request and match it to a cookie. If it matches, the admin is verified.
It's a little different from what you want of course, since I first set the key when the admin is logged in (it's an observer event). But it should get you started.
Source (NOT ready for production, use it for ideas): https://github.com/zschuessler/QuarkBar/tree/master/app/code/community/Zaclee/QuarkBar
Also, note that I'm storing the secure key so that I can access the admin backend. The solutions in your link say to disable it. You don't have to, check out QuarkBar for implementation.
I have some Ruby web apps that use OpenID for authentication and store the session in a cookie. There are a few API- and AJAX- related things that my Ruby frameworks aren't a good fit for, so I've got some node.js services. The problem is that if someone knew the URLs of my AJAX services, they'd basically be open to the public as things stand. At the moment those services do a simple check of the Origin header, but obviously that's very easy to forge.
So I want to be able to restrict access to the services running on Node (or Python, or in a non-Rack based Ruby service, or anything else) to users who are logged into the 'main' service that's run through a Rack-based web application. Are there any conventions for how this sort of thing is done? I've seen heaps of websites that will serve content and pages through example.com, and then the AJAX calls get made through api.example.com, so I'm surprised this is something I' haven't read about.
I do have an idea for how to do this, and I'd love some feedback on whether I'm missing something blindingly obvious that makes this insecure:
My Ruby web app uses OpenID for authentication and stores the session in a session cookie using Rack::Session. From looking at the Rack::Session source, my framework seems to go through this process:
generate a Marshal dump of my User object
generate a SHA1 hash of the Marshal based on a secret key
store a hex digest of the SHA1 hash in a cookie
So theoretically I could have a pre-arranged key or system for generating the key, or some message passing between frameworks through a secure channel to share the key. Then I could reverse the encryption process in any other framework that wanted to be able to verify session data. I'd have to get rid of the first step and only store JSON data or something instead of a Ruby object for cross-language compatibility, of course.
Is this considered a secure way to do things, assuming the protocols for sharing the key are appropriately secure?
What you're describing is a Message Authentication Code (MAC); in this case, it's a Hash-based MAC or HMAC. Basically, take a representation of the data you want to authenticate (make sure is coming from a certain source), append a secret key to it, and hash the whole thing. Then attach that computed hash to the message (what you just hashed minus the secret key). When the receiving party receives the message, it would take the data, append the same shared secret to it, and hash it. If that computed value is the same as the one received as part of the message, it is authentic and should be processed; if the hashes do not match, it is not from the party it should be from and should be discarded.
You may want to look at the RFC specifying the HMAC construct (just don't use the sample code as it still uses MD5; use something like SHA-256 or SHA-512 to implement your HMAC):
http://www.ietf.org/rfc/rfc2104.txt
I haven't had to tackle a login process before so this is new territory for me and all I seem to be finding on Google are conflicting methods of handling this process, so I was hoping someone could help clarify.
So far I have a salted SHA1 hash made from mixing username, password and my salt variable.
When the user logs in their credentials get hashed, then this hash gets sent to sql and if found comes back with a UserID (or something). So I know they are authenticated.
With that I can handle their session with session variables.
Is that right so-far?
Anyway, I wanted to have the option of "remember me" and was looking at storing something in a cookie but am not sure what to put in there as, as-far-as I am aware storing the hash would be pretty much the same as putting their username & password in plain text.
I'm confused, can anyone shed some light?
Thanks in advance
You are usually better off using the authentication methods provided by your platform than creating one yourself. There are a lot of non-obvious problems that you can easily leave yourself open to. Which platform are you using? Are you using a web framework?
General purpose hashes like SHA1 are inappropriate for password hashing as they are optimised to be very quick, when you want something that is very slow. For discussion of this, see How To Safely Store A Password.
Anyway, I wanted to have the option of "remember me" and was looking at storing something in a cookie but am not sure what to put in there as, as-far-as I am aware storing the hash would be pretty much the same as putting their username & password in plain text.
Hashes are designed to be one-way functions, so no, it isn't the same as putting their username and password in plain text. However if you do it that way, you'll have to create a way of letting somebody authenticate with the hash instead of their username and password, and that is the same as storing their username and password on the client (as far as you are concerned, anyway).
I like the fact that you have used salt for your hashing but I don't think it's necessary to use the username for hashing only password+salt should be enough. Specially it will inflict an overhead of rehashing if you want the option of changeable usernames for your system.
For remember me option, I don't think you should store any credentials at client side cookies. Only the session ID should be enough. If you want to make it really secure you should use client-side certificates that are issued by the server.
http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500
Your first login process is correct and up to todays security standards with the only exception that you may want to choose another hashing function over sha1.
Sha1 is very quick and therefore brute force attacks to crack a hash are faster. So if your hashes (database) and token (source code) get leaked, the passwords can be cracked.
One countermesure is to use a slower hashing function (see Jims answer for an article about that)
But the best of course would be not to leak your hashes in the first time.
A possibility for the remember me function is to let the user keep the session cookie for longer. For example Magento and Zend Auth does this.
This is however very ugly because you are likely to get hundrets of thousands of sessions stored on your servers, even for users that never return.
The far more elegant way is to store this information client side.
Sidenote: Of course you shouldnt put too many cookies on the client because they get transmitted with every page request. But a login cookie is a very valid case to do so. A good practice is to store the login cookie at the client side and populate the server session with data saved in a database at login which is marked in a session. This way you eliminiate continous database requests and have a good user data registry. Of course write has to be done to the database and session directly or better to the database and then somehow flushed to the application (full or incrementally).
Putting the hash in a client cookie isnt like "plaintext". However its ugly and awful and insecure on many levels.
There are some different approaches but they mostly involve some hashing again.
The most common and easy one is something like to put a cookie with user_id=john and user_token=HASH($userid.$appsecret) on the client. Or to store them as one in one cookie.
This is kinda secure but I prefer the following method:
Generate a string that holds:
userid ; user agent ; first two ip segments ; current timestamp ; your application secret token
Run it through a good hashing function and store a cookie at the users client that looks like
auth=userid;timestamp;hash-of-the-above
When the client logs in via cookie you re construct taht string from above but take the timestamp and user id from the cookie. Generate the hash and see if it matches. Then you have validated that it is the cookie you generated for that ip adress segment and this user agent at the specified time
Sidenote: first two ip segments rarely changes with dynamic isps. you can leave them away too, its for extra security.
What is the main advantage of thsi method?
The client or you can invalidate all login cookies by setting a timestamp. Only cookise that have been generated afterwards are accepted. You can also implement a timeout.
This is good if you want to "remote logout" form a public computer where you forgot to log out or something.
I think functionality is very important and with this method you dont have to keep track of single login cookies (like google does).
Hope this helps you.
You can scale this method to any level of security you like and adjust it to your needs.
your authentication is just fine. If you want to make it even more secure you could transmit the login information with a SSL encrypted connection so nobody can read what's going across the network.
The remember token is quite simple let's say you want a remember me function that is valid for 14 Days.
A stranger with no authenticated session comes to your site:
Check if there is a remember me token in a cookie
If yes, check if you can find this remember me token in your database and check if the "valid until" column is still valid (date comparison)
If you find a valid token you can set the user id and authenticate his session
If you don't find a valid token redirect the user to the login page if necessary
When the user fills out the login form and authenticates him sucessfully:
Generate a token using an appropriate hashing function. The token you hash could look like "[Timestamp]---[userpwd]" so it's (almost) definitely unique! Save the token and the date until the token is valid (+14 Days from now as example) to your database connected with the user's id. If there's an expired token, replace it because you don't need to store expired tokens.
If the user logs out by clicking the logout button or similar just delete the token record in your database and the user's cookie.
That's it!
If your platform (web server etc) supports HTTP digest authentication, i would strongly advise you to use it. It was designed by people who know more about security than either of us ever will. It doesn't send passwords over the network. It is supported by all modern web browsers, including mobile devices. If the browser has the password stored, it happens transparently during connection, giving you the 'remember me' functionality without needing to go anywhere near a cookie.
The only thing it doesn't do is let you use a nice form - the use will get a dialog box from their browser to log in.