Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security? #43

Open
WebVRRollerCoaster opened this issue Jun 10, 2016 · 5 comments
Open

Security? #43

WebVRRollerCoaster opened this issue Jun 10, 2016 · 5 comments

Comments

@WebVRRollerCoaster
Copy link

We are implementing this project into our application (front end is a Unity3D desktop/mobile app), can anyone comment on the security of the accounts information using this code?

@kevinaud
Copy link

I'm really not well versed on security, fair warning, but I'm pretty sure that for signing up and logging in users it is considered a good practice to hash their passwords before sending them to the backend, which this implementation doesn't do. What this does is it sets the password as a 'payload' for the CreateUser lambda function and then it invokes the lambda using the AWS SDK and sends the payload with the invocation. Then inside of the CreateUser function it hashes the password and stores it. I'm not entirely sure how the payload gets transferred from the web client to the lambda function when you invoke it via the SDK, but I assume it's over an http request of some sort. Since the password isn't hashed before it's sent to the function, that http request could be intercepted by some evil genius and then he or she could take note of the password before it gets to the function to be hashed. However if you hash the function on the front end, it doesn't matter if the http request gets intercepted because the password wouldn't be human readable. So that's something to consider, but again I'm not a security expert so take my advice with a grain (or maybe a mound) of salt.

@hhoughgg
Copy link

Not an expert either but you hash passwords before you send them to the database and then salt the hash so that if your database was compromised it would take a prohibitively long time to get access to large amounts of the stolen data. This implementation does that properly as far as I can tell.

When you send the HTTP request from the front end to the back end you don't need to hash the request but you should always be using https on your web server to make sure that if this information is intercepted it is not in plaintext form.

Hope that is somewhat helpful.

@WebVRRollerCoaster
Copy link
Author

@bluestreek18 @kevinaud Thank you very much for the answers, so I take it it is secure?

@aggied
Copy link

aggied commented Oct 13, 2016

In my experience (which is minor compared to many) I've never hashed the passwords coming from the frontend, only hash/salt before database entry.

I'm also interested in the security of this method, but from an AWS perspective.

  1. The login page, for example, contains AWS Cognito IdentityPoolId. I know VERY little about Cognito, I assume this is how it is supposed to be? I'm assuming so because I understand Cognito is intended for cross platform use, so the IdentityPoolId can be public.
  2. A Lambda function is invoked directly from the front end. I would think routing this request through the webserver would prevent an attacker from running up my Lambda function past limits. No?

@rjsoph
Copy link

rjsoph commented Jul 15, 2017

Hashing a password in the front end before sending to backend in effect makes the "hash" the password. This is not considered a good practice since a hash is by nature less unique than a password. Since the hashing is exposed to all clients and would be very simple to replicate it adds no real security.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants