I have read the other posts about password protecting your application, but my situation is a little different.
I still want password protection, but I want to create the passwords myself, and then once a password is used, no other user can enter it.
Lets say I have a list of passwords (hamAndCheese, hamAndCheese1, hamAndCheese2). If 1 person downloads the app from the app store and enters hamAndCheese, I want that password to be "broken" if another user tries to enter it.
Also, once a user enters the password once, I don't want them to have to enter it again. (Im less worried about this part, more about the part described above).
Should I just make a list of passwords? How do I eliminate them once they have been used?
Thank you
You could make a time-dependent password.
you generate a list of passwords, and the viability of the pw is only a few days. This makes reduces the risk that your passwords will travel after the time they are useful
Second option is a webservice that you built, and that validates the password over the internet
As stated before by tux91 - sounds like it could be used to generate a revenue stream outside the appstore, leaving big bad apple without it's 30% cut of your revenues
Related
I want to offer some paid content in the app but I don't want the user to go through an Authentication process. I would like him to enter the app and directly be able to buy some of the content and remember that this user has bought it if he comes back later or uninstall/reinstall the app later on. (Like most meditation app on the Store right now)
Is it possible using Firebase Services and if so, what would be the good way to track paid content for anonymous user?
An Anonymous user IS a user without details (Name, email, password, etc). It has a unique UserID
So YES. You can save anything to the database using the User's unique ID. But remember. Every app is capable of performing operations inside their sandbox directory. which also has a unique ID and resets when the app is uninstalled.
In a sentece. Firebase won't remember the Anonymous user ID if the app was deleted intentionally.
The docs does state this very well:
You can use Firebase Authentication to create and use temporary
anonymous accounts to authenticate with Firebase. These temporary
anonymous accounts can be used to allow users who haven't yet signed
up to your app to work with data protected by security rules. If an
anonymous user decides to sign up to your app, you can link their
sign-in credentials to the anonymous account so that they can continue
to work with their protected data in future sessions.
Read more:
Authenticate with Firebase Anonymously on iOS
You could theoretically set it up to where it would redirect the user to a TextField page asking him/her to make a "password" and "PIN" of sorts. This "password" and "PIN" could then be stored into a SQL server database as an anonymous user. When re-downloading the app you could have a page dedicated to purchase recovery where all a user would need to do is input this "password" and "PIN", after they have correctly entered both it would return purchases to their account.
things to be wary of:
-People may use the same password, which is why I recommended a PIN as a way of two-step authentication. Keep in mind also that your app will need to test the password against the server before uploading to make sure that the password doesn't already exist and tells the user that the password cannot be used in such case.
-This is essentially the same thing as an account with a username and password... the only difference is that you aren't going to be collecting other information on them, such as email and birthday, etc., making it more anonymous.
-This is a very rare case of question and I know this is a crappy answer, but honestly this isn't the best idea to implement unless your app heavily relies on it.
I cant find any help around on this topic because I am being told how to implement it rather than how it actually works.
All I know is two-factor authentication is authenticating users through an email and a phone number.
Here are my set of questions :
Does it authenticate users by verifying their email and phone number at the time of registration?
Does it authenticate users by verifying their email and phone number on every login?
Why is it that every user can set two-factor authentication enabled or disabled for their account? Isn't this an admin thing which should not be decided by the user?
I'll see if I can help clarify for you.
It works as an extra level of security. Traditionally you would have a username/email and password to get into a site. If the password is compromised then so is the account. Adding a phone number to your account will mean that only someone with access to that phone can get past the extra level of security and access your data.
When the user logs in with another 'step' is added before they get through. A token (usually a number with a short expiry - i.e. seconds) is tied to the user logging in and sent to their phone. They fill in the form and submit. The device the user is logging in with (laptop/phone/desktop browser) can then be tied to their account (see point 2 below).
This can be the case but if you take Google as an example you can select to 'Trust' the device logging in for 30 days. This ties the device to a trusted list (perhaps stored in a database for instance) for a set amount of time before asking at the point of login again.
Common practice is that it is the user's choice as to whether they have this extra level of security. They may not have access to a phone...what happens then? They may like the convenience of just using a username/email and strong password....it doesn't mean to say you can't force it by design in your system though.
I'm writing an ASP.NET MVC application, which uses the Membership database to store user registrations. I use email addresses as usernames. When a user registers in my app, I send out an email-confirmation to the address they have used during registration. i.e. I send out an email with a link, which the user is supposed to click, to verify that the address belongs to him.
Until that link is clicked, the account remains 'Unconfirmed' (i.e. EmailConfirmed column equals False). Which means, the account is created, just not active.
How do I deal with a hacker who brute-force creates accounts? I see two big problems here:
Ever-increasing size of the Membership database. A single user, from
a single computer is not a threat, but what if he has 'zombie'
computers?
If User1 creates account with User2#example.com email and
User2 ignores the activation email, the account will essentially
remain locked (unconfirmed), but existing. If User2 decides later to
actually create an account, they can't use their email to register
(account already exists) and they can't Reset Password either -
because even if they reset the password, that does not necessarily
Activate the account.
As for 2) I see a couple of options:
Set expiration date on unconfirmed accounts - i.e. allow the username/email to be claimed again, if the email is not confirmed with 24hrs
Modify my Reset Password method to also activate the account, if it has not been activated. Is that a good idea? I mean, the person would receive an email for that, which is essentially a confirmation, if they click the reset password link in it.
Anything else?
What about 1)? How do I protect myself against bulk create of accounts? Aside from limiting 1 account per IP, per day, using code.
One simple way to deal with this kind of problem is crude but effective.
I usually add an additional field to the form that doesn't form part of what I need - but has a legitmate sounding name like 'Company' - and then I hide it from screen view using CSS. Real user's will never see this on screen, but a bot crawling through the HTML will find it.
Then, when the form is submitted, first I check to see if that form field has a value. If it has - I stop the page from executing any further or just return an HTTP Error as in 99.9% of times only a bot would have filled out that field - not a real user.
//anti-bot measure
if (!String.IsNullOrEmpty(Company.Text))
{
HttpContext.Current.Response.StatusCode = 400;
HttpContext.Current.Response.Status = "400 Bad Request";
HttpContext.Current.Response.End();
}
//carry on processing the form...
I've been using this technique on forms for several years and it's been extremely effective!
I am currently worrying about a password recovery method for users of a web application.
One idea would be to use an E-Mail with a recovery url, only asking the user for his/her user name, but if he/she forgot that too, ask for e-mail address.
Another idea would be to use "secret questions" and then send the password to the user.
Do you know any other, possibly better, options for password recovery? Are there any downsides, besides user frustration, to have a "wrong password limit"?
EDIT:
Yesterday I was told that in some of the older versions, which are still updated and used by some customers, neither E-Mail addresses nor user names have to be unique.
So I'm totally stuck now. The only thing coming to my mind is using a secret question which the user can select after first login. But instead of sending an E-Mail opening the "new password dialog" directly.
Do you have any more ideas?
My opinons:
Assuming you require a user's email address to be unique among all registered users have the password recovery page ask for the user's email address. You can make it "username or email address" but I don't think that little tweak will help enough users to justify your additional backend processing.
For added security do not confirm or deny that the username or email address was found in your database.
An email with a reset password link should work fine. Use a hash (the longer the better; definitely 20 characters or more) so a hacker can't easily guess reset links. For added security specify a time limit after which the reset link will no longer function.
Once the user clicks the link and chooses a new password, do not automatically log them into their account; make them login from scratch. This will make sure they know their new password and will reduce the chances of a bug in your password recovery code letting hackers directly login to accounts.
Remind users to check their spam folder, and provide a window of time in which they can reasonably assume they should receive the reset link (so they know how long to wait before complaining to you).
Security questions are usually a bad idea. First off, users struggle to remember what their answer was. It's like adding something to a user's password but giving the world a hint to what that extra part could be. AND the answers will tend to be case insensitive and only alphabetic or alphanumeric.
Make sure you include a way for the user to contact you if the password recovery system isn't working for them. Be cautious, though, as this could be an avenue for a Social Engineering hack.
Password limits can be frustrating for users. Think long and hard about implementing this, how many attempts you'll allow, and the consequences of exceeding that limit. Most people have variations of a single password. Now, that's not smart from a security standpoint, but it happens. A reasonably acting user could very well try hooper2012, Hooper2012, hooper20121, Hooper20121 in under a minute.
Maybe you could, say, after five failed attempts make the user wait 60 seconds between any future attempts. Double that to 120 seconds after an additional five failed attempts. Continue doubling the wait period every five failed attempts. If you let that continue until, say, 50 consecutive failed attempts the minimum amount of time it'll take to exhaust those 50 attempts will be 1 day 18 hours and 35 minutes. I'd definitely recommend having something in your code to notify you of any accounts with more than 12 consecutive failed attempts in a day.
After 50 consecutive failed attempts temporarily deactivate the account, and require the user to contact your technical support. Again, be wary of social engineering.
Reset the wait period to 0 once the user provides the correct login credentials.
I think this is a simple one, I want to display the authentication key during a password reset.
First, is there any problem with doing so? Is there some kind of hole I'm opening up? I control when a user is created and sent signup_instructions. I only have about 500 users. My system is one where in many cases, it is only used a few times a year, and by only one or two employees at smallish companies , average 10 employees. Some of the companies we service , rather than create multiple accounts for employees, share one or more accounts, i.e. I create it for a specific person at the company, then they share the password with their assistant(s). I use email addresses for authentication key.
Can you guess what's coming next? This really happened! User goes on vacation, young assistant needs to log in, forgot the password, but is savvy enough to click forgot password and reset it, she reads bosses emails while boss is gone. Boss returns from vacation, needs to log in, can't, but isn't savvy enough to click forgot password and didn't bother to read her emails that came in while she was gone. So she calls in a panic and pissed off, 'what's wrong, I can't log in!!!'. Many of my users are like that, older, not real computer literate.
So I need to take extra steps to idiot proof resetting passwords, which I'm thinking should include PROMINENT display of the email address they are about to reset, plus wording to remind anyone who's 'sharing' an account to inform their co-workers if they reset.
I tried this in my devise/passwords/edit
<%= resource.email %>
The above code yields nothing!
You should never expose authentication data. That's why you never send them with GET but instead with POST. Do some research: how does gmail reset passwords? Another thing to remember, once you have done all that's reasonable, a user is responsible for safeguarding his personal information. If the secretary knows everything about the boss, then that's too bad -- unless they want you to use biometric to reset passwords.