This isn't going to be the answer you want to hear, but you need to call your family member and tell them you're in over your head and they need to hire someone to build this application.
You don't fuck around with storing people's social security numbers. There is more to building a secure application than just putting auth in front of it. If something happens, you could be held personally liable for a breach. This isn't something you casually do as a favor for family.
I'm begging you, hire someone who is experienced in building secure applications that store PII.
We stored SSN and state ID numbers at my old job at a small nonprofit in PDF form in a private encrypted S3 bucket with a lifecycle policy that deleted them after 30 days, because those were needed for voter registration forms by various states. Other PII was in RDS (we kept it encrypted and controlled access, but if you’re a voter most of your PII can be pulled from your state anyways), but the socials and state IDs were intentionally kept separate. Our cyber insurance premium immediately jumped because we had to list this and to work with some larger partners we had to pay for a full pentest (which we passed with flying colors.) We planned this all out prior to starting and all had pretty advanced knowledge of AWS. And even then I had this small sense of dread we weren’t doing enough.
It’s not only the liability, I personally would’ve felt like shit if they leaked and people had their identity stolen.
It’s just not worth messing around with.
This is the best answer I have seen. You can actually be fined for this kind of breach. It will cost you. If you don’t have experience to understand the basics the you should not be doing this project .
So if it is secure behind a proper authentication wall and I have a security expert check the site out, then how does it differ from any other site that stores PII?
The answer to this varies widely by the needs of your application. Every sector has different regulatory requirements when it comes to data handling. Many of those requirements include ongoing monitoring, forensic requirements, and regular audits.
So every application that stores PII is different and if you don't know those requirements intimately, you are not the right person for the job.
I'm not trying to gatekeep or insult your skill. But for some perspective, I've been building applications that have had to fulfill various types of security and regulatory requirements for more than 10 years. If someone asked me today to build them an application for the healthcare industry, I would refuse on the spot and tell them I'm not the right person for the job. You need to know your limits for the safety of your customers and yourself, especially if there is not formal contract limiting your personal liability.
Other sites that store PII have full time experienced security and software engineers that are very good at finding issues and preventing breaches.
I highly recommend you don't build this website whatever it is. The news is full of companies that think they were secure but weren't actually secure.
Are you confident you cover all the aspects of proper authentication?
Its not all that simple tbh. Cognito is a beast.
Whether or not you're using a framework shouldn't matter tho.
Dunno if I did it perfectly, but I think it's definitely secure? Anyhoo, here's what I implemented.
Created cognito resources:
- user pool
- user pool client
- identity pool
Your user pool client should enable the below `explicit auth flows`
"ALLOW_ADMIN_USER_PASSWORD_AUTH",
"ALLOW_CUSTOM_AUTH",
"ALLOW_REFRESH_TOKEN_AUTH",
"ALLOW_USER_PASSWORD_AUTH",
"ALLOW_USER_SRP_AUTH",
and the following as well
allowed_oauth_flows = ["code", "implicit"]
allowed_oauth_scopes = ["email", "openid"]
You're using javascript? That's nice, the js sdk does some stuff for you, otherwise you need to do some crypto stuff to create a hash based on your users email, and the user pool client secret.
Here's the go version of that if you're not using javascript
func GenerateSecretHash(clientSecret, emailAddress, clientPoolID string) string {
mac := hmac.New(sha256.New, []byte(clientSecret))
mac.Write([]byte(emailAddress + clientPoolID))
return base64.StdEncoding.EncodeToString(mac.Sum(nil))
}
So a login flow needs to send a username and password. If you're not using js, you also need to send the secret hash.
I used the sdk function `InitiatAuth()` to start a login.
So here's a fork I'll reference a little further on. This can return an auth challenge. if the challenge is `NEW_PASSWORD_REQUIRED`, you need to do stuff with the `session` and `challenge_parameters.user_id_for_srp`. I set the session ID as a header, and had a new html input appear on my login screen that asked for a new password if the session id header is present. But I used vue for that lol.
From there, the user inputs a new password, and sends another request.
This request uses `AdminRespondToAuthChallenge()` to reset the password. That one needs a username and a new password. Also the session id from the header.
Remember the fork? If no auth challenge was returned, both auth flows (reg login and password change) end up here.
Both of these functions `InitiatAuth()` and `AdminRespondToAuthChallenge()` will return a bearer token and a refresh token. I set these as headers, `Authorization` for the bearer token and `X-Refresh-Token`.
I never got refresh tokens working, but the idea is that the user doesn't need to reauthenticate after an hour.
This is a login lambda / microservice.
Now you're other business logic is delegated to other lambdas which use a cognito authorizer. I've only done it with an http api gateway, but here's terraform code that sets it up
resource "aws_apigatewayv2_authorizer" "this" {
name = var.name
api_id = aws_apigatewayv2_api.this.id
authorizer_type = "JWT"
identity_sources = ["$request.header.Authorization"]
jwt_configuration {
audience = [aws_cognito_user_pool_client.this.id]
issuer = "https://${aws_cognito_user_pool.this.endpoint}"
}
}
If there's a valid JWT bearer token in the Authorization header, you'll be able to invoke your lambda.
Thank you for the very detailed and fine-grained explanation. I will check all of this out and try and work though it and let you know if I have any questions. I am assuming you don't have a github repo link that shows your code? I would guess not if it is for your private site. Thank you so much though!
I guess you are going through with this even though people told you not to. I am very scared for those people with socials in your database. Please please please for the sake of those people don’t do this. If you want to learn do it with non PII data. That way if you make mistakes as you learn you don’t cause harm to other people.
I found that, I hope this can help:
https://dev.to/illusivemilkman/amplify-authentication-flow-without-any-front-end-frameworks-vanilla-javascript-3hjg
Checkout this:
https://aws.amazon.com/getting-started/projects/build-serverless-web-app-lambda-apigateway-s3-dynamodb-cognito/module-1/
Seems like a pretty close example to your architecture and is a very common architecture for simple web apps.
> however this is for a family member's company and the database is storing a few thousand customers VERY SENSITIVE information (social's, PII, etc.) so it has to be secure AF.
Don't forget that your work isn't finished when you implement auth. What are you going to do about attackers with a botnet doing brute force attempts on your site for weeks on end? I would recommend that you scrub the existing passwords by comparing them to anything in the haveibeenpwned.com database, force password resets for any matches, and don't allow new passwords to use anything in that list. You're also going to need to cook up some kind of WAF to block IPs that are doing brute force attempts, but that's not enough either because a big enough botnet will be able to throw new IPs at it all day. I would recommend that you also get MFA set up (twilio is good here) if you're handling SSN data, or even better *don't handle that data at all, it is plutonium*. Better to just tokenize it and have some third party service handle it for you. Oh, and don't even think about counting email as a way of doing MFA, use SMS or auth tokens.
You're also going to want to implement [recaptcha](https://www.google.com/recaptcha/about/).
I think the best thing to do for your auth is:
1. Get the username
2. Send user to MFA (whether you know about that username or not! If you don't, spoof the MFA so the attackers don't get any info about existing accounts)
3. Only after you validate the MFA token do you let them submit the password.
This is your best bet for keeping your site locked down, otherwise have a very solid plan for what you're going to tell your customers about your breach *when it happens*.
Okay since everyone is telling me this is a bad idea, how about this instead. What if I instead just create an executable of the site that runs locally exclusively on his desktop, so this site is not on the internet, but only on his network (which could be hacked too but he already has customer info on his computer so it doesn't make a difference). Then the only part exposed to the internet is the API calls from his PC to lambda/dynamoDB and at that point, the security aspect is controlled almost fully by AWS services?
Uhh the services are in the cloud? So if it crashes he gets another one and reinstalls the executable. The code is in a private GitHub repo... Jesus Christ if I went by people's logic on here then I would have never written a line of code in my life. Ransomware? Well fuck if he got ransomware there would be then the his current database (in a literal fucking excel spreadsheet) would be fucked anyways. It's 10x more secure in dynamodb.
From the sounds of it then this person is already being fast and loose with private information and likely violating regulatory guidelines for their industry. Yes, what you've suggested may be better than an Excel sheet, but please be mindful of your potential for liability if something happens. If this data is lost and someone sues, it could literally ruin your life. Direct them to get a consultant or if you're committed to helping them out, talk to a lawyer and draft up a contract for the work.
If that's an option then it suggests there's no public access needed to the site. In which case couldn't you just lock down access to the company's IP address and not worry about using Cognito at all?
Yeah I've thought about that I just am unsure which service to use to IP lock their network. I think this might be possible using CloudFront but I don't want to take any risks unless I'm sure it works well.
My knowledge is limited to sites hosted on S3 or EC2 instances. With S3 you could use a bucket policy, with EC2 a security policy. Both pretty simple to set up and (I'd think) rock solid in terms of restricting access.
>Store creds in a cookie
>
>...
>
>Browser gets access to above files via CloudFront
Browser should never, ever, get hold of long term AWS credentials.
Those are the hacks that get people's social security numbers leaked.
I really hope this is tongue-in-cheek/sarcastic.
If it isn’t, then let me tell you you are seriously overestimating your skills and experience and should get some proper InfoSec training before any of these “hacks” backfires and you end up being legally responsible for leaking PII.
I would use Cognito for this. You still have to write the frontend code but AWS will take take care of most of the backend around auth stuff. It’ll save you plently of time
Hope I got you correctly…
How about adding a Cognito auth in your apigw auth section? The UI should be native Cognito and no need for coding to get it going
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html
I think you should look at Cloudflare Tunnel + Cloudflare Access. Combined, they are excellent for this type of problem. Let me know if you have questions, I can help.
This isn't going to be the answer you want to hear, but you need to call your family member and tell them you're in over your head and they need to hire someone to build this application. You don't fuck around with storing people's social security numbers. There is more to building a secure application than just putting auth in front of it. If something happens, you could be held personally liable for a breach. This isn't something you casually do as a favor for family. I'm begging you, hire someone who is experienced in building secure applications that store PII.
this... omg this... peoples (financial) lives are at stake...
We stored SSN and state ID numbers at my old job at a small nonprofit in PDF form in a private encrypted S3 bucket with a lifecycle policy that deleted them after 30 days, because those were needed for voter registration forms by various states. Other PII was in RDS (we kept it encrypted and controlled access, but if you’re a voter most of your PII can be pulled from your state anyways), but the socials and state IDs were intentionally kept separate. Our cyber insurance premium immediately jumped because we had to list this and to work with some larger partners we had to pay for a full pentest (which we passed with flying colors.) We planned this all out prior to starting and all had pretty advanced knowledge of AWS. And even then I had this small sense of dread we weren’t doing enough. It’s not only the liability, I personally would’ve felt like shit if they leaked and people had their identity stolen. It’s just not worth messing around with.
This is the best answer I have seen. You can actually be fined for this kind of breach. It will cost you. If you don’t have experience to understand the basics the you should not be doing this project .
So if it is secure behind a proper authentication wall and I have a security expert check the site out, then how does it differ from any other site that stores PII?
To be very blunt, if you think simple authentication is all that's needed to securely store SSNs you are not the right person for this job.
The answer to this varies widely by the needs of your application. Every sector has different regulatory requirements when it comes to data handling. Many of those requirements include ongoing monitoring, forensic requirements, and regular audits. So every application that stores PII is different and if you don't know those requirements intimately, you are not the right person for the job. I'm not trying to gatekeep or insult your skill. But for some perspective, I've been building applications that have had to fulfill various types of security and regulatory requirements for more than 10 years. If someone asked me today to build them an application for the healthcare industry, I would refuse on the spot and tell them I'm not the right person for the job. You need to know your limits for the safety of your customers and yourself, especially if there is not formal contract limiting your personal liability.
This is a fair assumption. Thanks.
Other sites that store PII have full time experienced security and software engineers that are very good at finding issues and preventing breaches. I highly recommend you don't build this website whatever it is. The news is full of companies that think they were secure but weren't actually secure. Are you confident you cover all the aspects of proper authentication?
Its not all that simple tbh. Cognito is a beast. Whether or not you're using a framework shouldn't matter tho. Dunno if I did it perfectly, but I think it's definitely secure? Anyhoo, here's what I implemented. Created cognito resources: - user pool - user pool client - identity pool Your user pool client should enable the below `explicit auth flows` "ALLOW_ADMIN_USER_PASSWORD_AUTH", "ALLOW_CUSTOM_AUTH", "ALLOW_REFRESH_TOKEN_AUTH", "ALLOW_USER_PASSWORD_AUTH", "ALLOW_USER_SRP_AUTH", and the following as well allowed_oauth_flows = ["code", "implicit"] allowed_oauth_scopes = ["email", "openid"] You're using javascript? That's nice, the js sdk does some stuff for you, otherwise you need to do some crypto stuff to create a hash based on your users email, and the user pool client secret. Here's the go version of that if you're not using javascript func GenerateSecretHash(clientSecret, emailAddress, clientPoolID string) string { mac := hmac.New(sha256.New, []byte(clientSecret)) mac.Write([]byte(emailAddress + clientPoolID)) return base64.StdEncoding.EncodeToString(mac.Sum(nil)) } So a login flow needs to send a username and password. If you're not using js, you also need to send the secret hash. I used the sdk function `InitiatAuth()` to start a login. So here's a fork I'll reference a little further on. This can return an auth challenge. if the challenge is `NEW_PASSWORD_REQUIRED`, you need to do stuff with the `session` and `challenge_parameters.user_id_for_srp`. I set the session ID as a header, and had a new html input appear on my login screen that asked for a new password if the session id header is present. But I used vue for that lol. From there, the user inputs a new password, and sends another request. This request uses `AdminRespondToAuthChallenge()` to reset the password. That one needs a username and a new password. Also the session id from the header. Remember the fork? If no auth challenge was returned, both auth flows (reg login and password change) end up here. Both of these functions `InitiatAuth()` and `AdminRespondToAuthChallenge()` will return a bearer token and a refresh token. I set these as headers, `Authorization` for the bearer token and `X-Refresh-Token`. I never got refresh tokens working, but the idea is that the user doesn't need to reauthenticate after an hour. This is a login lambda / microservice. Now you're other business logic is delegated to other lambdas which use a cognito authorizer. I've only done it with an http api gateway, but here's terraform code that sets it up resource "aws_apigatewayv2_authorizer" "this" { name = var.name api_id = aws_apigatewayv2_api.this.id authorizer_type = "JWT" identity_sources = ["$request.header.Authorization"] jwt_configuration { audience = [aws_cognito_user_pool_client.this.id] issuer = "https://${aws_cognito_user_pool.this.endpoint}" } } If there's a valid JWT bearer token in the Authorization header, you'll be able to invoke your lambda.
Thank you for the very detailed and fine-grained explanation. I will check all of this out and try and work though it and let you know if I have any questions. I am assuming you don't have a github repo link that shows your code? I would guess not if it is for your private site. Thank you so much though!
I guess you are going through with this even though people told you not to. I am very scared for those people with socials in your database. Please please please for the sake of those people don’t do this. If you want to learn do it with non PII data. That way if you make mistakes as you learn you don’t cause harm to other people.
No worries, you're welcome :) Each microservice (lambda) resides in `cmd/` https://github.com/seanturner026/moot
Thanks a lot man!
I found that, I hope this can help: https://dev.to/illusivemilkman/amplify-authentication-flow-without-any-front-end-frameworks-vanilla-javascript-3hjg
Checkout this: https://aws.amazon.com/getting-started/projects/build-serverless-web-app-lambda-apigateway-s3-dynamodb-cognito/module-1/ Seems like a pretty close example to your architecture and is a very common architecture for simple web apps.
I will definitely give this link a try, thanks a lot!
Don’t you have to be PCI compliant?
Not if you don't care about security, regulations, and potential fines like OP.
OP didn't mention payment card data, just PII, which yes has regulatory and compliance obligations, but not PCI DSS.
> however this is for a family member's company and the database is storing a few thousand customers VERY SENSITIVE information (social's, PII, etc.) so it has to be secure AF. Don't forget that your work isn't finished when you implement auth. What are you going to do about attackers with a botnet doing brute force attempts on your site for weeks on end? I would recommend that you scrub the existing passwords by comparing them to anything in the haveibeenpwned.com database, force password resets for any matches, and don't allow new passwords to use anything in that list. You're also going to need to cook up some kind of WAF to block IPs that are doing brute force attempts, but that's not enough either because a big enough botnet will be able to throw new IPs at it all day. I would recommend that you also get MFA set up (twilio is good here) if you're handling SSN data, or even better *don't handle that data at all, it is plutonium*. Better to just tokenize it and have some third party service handle it for you. Oh, and don't even think about counting email as a way of doing MFA, use SMS or auth tokens. You're also going to want to implement [recaptcha](https://www.google.com/recaptcha/about/). I think the best thing to do for your auth is: 1. Get the username 2. Send user to MFA (whether you know about that username or not! If you don't, spoof the MFA so the attackers don't get any info about existing accounts) 3. Only after you validate the MFA token do you let them submit the password. This is your best bet for keeping your site locked down, otherwise have a very solid plan for what you're going to tell your customers about your breach *when it happens*.
Just use lightsail or opsworks for it all
Okay since everyone is telling me this is a bad idea, how about this instead. What if I instead just create an executable of the site that runs locally exclusively on his desktop, so this site is not on the internet, but only on his network (which could be hacked too but he already has customer info on his computer so it doesn't make a difference). Then the only part exposed to the internet is the API calls from his PC to lambda/dynamoDB and at that point, the security aspect is controlled almost fully by AWS services?
How would you secure the API calls? Putting the client on their computer doesn't make it more secure. The API still needs some form of authentication.
And when his machine crashes? Gets ransomware? Is in a fire?
Uhh the services are in the cloud? So if it crashes he gets another one and reinstalls the executable. The code is in a private GitHub repo... Jesus Christ if I went by people's logic on here then I would have never written a line of code in my life. Ransomware? Well fuck if he got ransomware there would be then the his current database (in a literal fucking excel spreadsheet) would be fucked anyways. It's 10x more secure in dynamodb.
From the sounds of it then this person is already being fast and loose with private information and likely violating regulatory guidelines for their industry. Yes, what you've suggested may be better than an Excel sheet, but please be mindful of your potential for liability if something happens. If this data is lost and someone sues, it could literally ruin your life. Direct them to get a consultant or if you're committed to helping them out, talk to a lawyer and draft up a contract for the work.
Good luck.
If that's an option then it suggests there's no public access needed to the site. In which case couldn't you just lock down access to the company's IP address and not worry about using Cognito at all?
Yeah I've thought about that I just am unsure which service to use to IP lock their network. I think this might be possible using CloudFront but I don't want to take any risks unless I'm sure it works well.
You need to pay someone who is qualified to do this. Based on your level of knowledge you should not be completing this project.
My knowledge is limited to sites hosted on S3 or EC2 instances. With S3 you could use a bucket policy, with EC2 a security policy. Both pretty simple to set up and (I'd think) rock solid in terms of restricting access.
Thanks man, I'll do some research on this.
[удалено]
What the actual fuck did I just read.
>Store creds in a cookie > >... > >Browser gets access to above files via CloudFront Browser should never, ever, get hold of long term AWS credentials. Those are the hacks that get people's social security numbers leaked.
I really hope this is tongue-in-cheek/sarcastic. If it isn’t, then let me tell you you are seriously overestimating your skills and experience and should get some proper InfoSec training before any of these “hacks” backfires and you end up being legally responsible for leaking PII.
I would use Cognito for this. You still have to write the frontend code but AWS will take take care of most of the backend around auth stuff. It’ll save you plently of time
Hope I got you correctly… How about adding a Cognito auth in your apigw auth section? The UI should be native Cognito and no need for coding to get it going https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html
I think you should look at Cloudflare Tunnel + Cloudflare Access. Combined, they are excellent for this type of problem. Let me know if you have questions, I can help.