I am working on an iOS app using Amazon Web Services and I am setting up a user data base using the Cognito Userpool. During the sign up process, if a user enters the wrong phone number by mistake and in result isn't receiving a verification code, I am trying to allow them to then enter a new phone number, and update their phone number user attribute. Right now I am using a Lambda function which uses the AdminUpdateUserAttribute function, which is then connected to a APIGateway which allows me to run it from XCode. The function itself works and it successfully updates the phone number attribute.
Problem
The problem that I am running into though, is that after the phone number attribute has been updated with the Lambda function, a verification code is automatically sent to the newly updated phone number via SMS. The verification code is weird though because when I use that code to confirm the user, it doesn't work. Meaning that code is invalid for confirmation purposes. But if I use the Resend Confirmation Code function it will then send a valid confirmation code to the newly updated phone number.
Question
So I guess the questions I have are:
How can I prevent the automatic SMS from sending after I update the user's phone number attribute?
Or, is there a way I can use the verification code that is automatically sent as a confirmation code?
Thank you in advanced.
Related
I have the "happy path" of signing up a user implemented using Flutter & AWS Amplify. I have made the user to verify their account using their phone numbers so that the verification code is sent to the phone and the signup process is completed.
I realised that, during testing, one could easily make a mistake. So I want the user to be able to go back and change the phone number so that the verification code is sent to the correct one. However, using Amplify, you cannot change the details if the user is not signed in, and the user cannot be signed in unless their account is "confirmed". Of course, their account cannot be "confirmed" if they don't receive the verification code and with the wrong phone number due to their mistake, they will never receive the verification code...
Has anyone faced the same problem and could help me how to solve this please?
I read that you could use Lambda functions to "auto-confirm" the account without any verification which means they can sign in, which would allow me to change their phone number if they have entered a wrong phone number. But I am not sure if this is the easiest way to do it
looking for some help with the auto-fill OTP function for my app while using Firebase authentication service. Auto fill functionality works fine in test app as sms has the hash code. But when I publish the app on Google Playstore, the hash code in the OTP authentication sms is replaced by the app name, and hence the sms auto fill stops working as it requires the hash code. Will be great if someone has come across this problem and can help with some solution or workaround.
What's is the workaround to this
I faced the same issue and mine was due to the app name too long to contain the hash-code. Below are few work around:
You need to make sure the message you receive contains the hash of your app. Below is the right format :
123456 is your verification code for %APP_NAME%.
xyz_hascode_123
If your SMS does not contain the hashCode at the end, you might have to shorten your app name to less than 16 characters.
If your app is already published on Google Play, the name in the SMS will be the same as the one in the GooglePlayStore.
If you changed the name to 15 characters and the error still persists, you might have to wait for at least 24hours for the change to reflect on Firebase.
If after all the above it's still not resolved, please check if your receiver is well configured in the code.
Check out the new GooglePlay policy on app names: Common app names violations
I have a REST Api with following path for user to register:
send verification code (/phone-code) -> 2. verify code (/verify) -> 3. enter personal information and register (/sign-up).
On the second step I mark phone as validated if entered code is correct and on the third step i check if phone is marked as validated. But imagine one person verifies the phone and another (let's say a hacker) tries to skip first 2 steps and triggers /sign-up with first person's phone. As the phone is already validated, a hacker registers successfully.
So the question is how to make /sign-up safe? One idea that comes to my mind is double-check code on the second and the third steps. But that comes with a coast of increasing the duration of validation code which is not very safe. Could you advise me something better?
Use some kind of session system on your service that uses cookies. When you sign up and verify, you remember the phone number and whether it was verified in the session.
You shouldn't have to ask for the phone number again, because the phone number should be known and in the session.
I am building a Java web application with TOTP getting generated(using TOTP Algorithm) and sent via mail. How would I authenticate it?
With my extensive research,I could find all the papers showed mobile devices authentication(Google Authenticator etc. ), my application is not using mobile device in any case, just a simple OTP authentication( received in user mail id)
OTP generate function goes like this:
OTP.generate("" + key, "" + System.currentTimeMillis(), 6, "totp")
See the RFC, then you know how to verify the Otp value.
https://www.rfc-editor.org/rfc/rfc6238
If you send the OTP value via email the server can just save and remember the value it sent.
Or when the user enters the OTP value, you can recalculate the value based on the key.
If you only send values via email, than you could also send any random string.
But maybe you want to do a more common approach - why not allow Google Authenticator and Hardware tokens with TOTP?
But if you are building a web application, maybe you would like a more generic solution in the background. privacyIDEA is an open source solution, that has all this right from the start. TOTP with Google Auth, hardware token or OTP via Email and SMS. No need to reinvent the wheel.
TOTP is useful when the Code Generator (typically a mobile or desktop app such as Google Authenticator) and the Code Validator (the authentication server) are two different entities.
In your case the application acts a both the Code Generator and the Code Validator so I would use a different approach in this case. Have you looked at HOTP? TOTP is in fact based on HOTP, the difference is that while the later uses an explicit counter as the moving factor (i.e. event-based moving factor), TOTP's moving factor constantly changes based on the time passed since an epoch. (i.e. time-based moving factor).
A problem you may run into with sending time based OTP codes via email is the potential lag between the code being sent, and the code being received. Given the OTP code has to be entered within a short period of time if this lag is too large then the code will not be usable.
I am working on an iPhone application where I need the user's phone number. From what I've read (here for instance - Programmatically get own phone number in iOS), the device's phone number is not available within your application's container. I've always had the user enter his or her own number. But when I joined GroupMe the other day, after clicking the Get Started button, my phone opened up a drafted text message to some US area code number "Send this text to verify your phone number(b2bd308eb7)" After I sent the text, the app knew my number....how does one implement a system like this?
What GroupMe does is use the MessageUI Framework ( http://developer.apple.com/library/ios/#DOCUMENTATION/MessageUI/Reference/MessageUI_Framework_Reference/_index.html) to send a text message to their servers.
Basically it works like this:
The app is turned on and calls the server.
The server responds with a code b2bd308eb7.
The app sends that code via SMS to the server.
The server gets the code and your phone number (from SMS) and confirms them.
Your phone number and app are connected!
They send a text message to some service that they can query with their server. So by sending the code to the server, they can verify the number,