Instead of using a standard password (all characters are allowed, min 5 characters, common passwords not allowed), you're able to login with a 4 digit passcode. I know someone just cringed at that thought, but the idea centralizes around improving user experience on the website.
First, all normal precautions would be taken (no common digit patterns - 1234, 1111, 2222, etc). There would also be a limit of two attempts before the passcode is reset. The reset procedure would be them receiving a new passcode via SMS, and them having to reply "yes" before the account is unblocked. The passcode is also reset every month, and a new one is sent via SMS to your phone (you can reply to change the passcode to something else).
Now for the issues I would need to address before this is even a possibility:
1) Users on the website login with their phone number, so one obvious attack would be someone cycling through all possible phone numbers with the same passcode (for example 8237). One suggestion in the article was detecting average error rates and comparing them to see if the entire website login should be throttled.
2) If someone somehow gets a hold of the database, all passcodes would be easily crackable. Now usually this would be a huge issue, but this is because normally people could use the email/password combination to login to other websites the user might use. Since they're using 4 digit passcodes, this wouldn't apply.
3) Someone could write a script to try phone number/passcode combinations until the entire website has their passcode reset, but this would fall under 1) where the error rates would exceed the normal limits and the logins would be throttled.
4) What would be an appropriate way to throttle? I mentioned it twice above, and in the article it was referring to a timeout, but the user experience of this would negate all benefits of a 4 digit passcode. Someone could keep trying combinations, and keep throttling the site every day. I could block the ip's, but what if those ip's were also sources of legitimate traffic and stopping users from logging in/signing up.
But this 'new' approach feels like last decade online banking - and it wasn't a good idea at that point.
In addition: Limiting user input and forcing password resets is, in my world, directly acting against your idea of 'improving user experience'.
If I am allowed to use a password of my choosing, I'll probably come up with something that is memorable and reasonably secure (depending on the context, I admit). If you force me to follow random, voodoo rules (just digits, at least one digit and one upper-case letter, more than x but LESS THAN y chars) I'm going to sigh, come up with something like 'YeahRight123' and I'm going to add a mental note to never trust this service fully. If I'm not leaving right away, that is. Resetting a password regularly (oh.. I hate everything noticeable SOX forces upon us)? Cool, you just motivate me to make my passwort 'cool123' - 'cool234' etc. (with variations for 'clever' password checks. If I cannot keep a prefix, I'll juggle different parts and keep the same, crappy, useless, insecure password, because .. I cannot be bothered to follow arbitrary idiot rules)
Your idea follows the worst practices in terms of restricting the keyspace and auto-resetting the password at arbitrary times, starting out weak already (4 digits..).
I wouldn't sign up with some 'security' in place that follows your suggestion.
What if the user was to authenticate once via SMS (we send them a code and they enter it within a reasonable time period), and once they do, they're authenticated for an infinite amount of time. This way they don't need to remember a passcode, and just need to have their phone on them when accessing the website from a new computer - a similar experience to two factor auth.
Was it Twitter who had their domain hijacked by someone ringing up the right telco and saying something like "my cell pone is out of action temporarily, can you please forward all calls/messages to this other number?" in a sufficiently convincing fashion to some minimum wage telco support staff, then getting a two factor auth token sent to an attacker controlled number?
I think a lot of webdevs make assumptions about SMS "security" that are quite unfounded.
"The lobby group for Australian telcos has declared that SMS technology should no longer be considered a safe means of verifying the identity of an individual during a banking transaction."
Why? All you are doing is further reducing an already limited key space.
This authentication scheme is bad, and you should feel bad. :)
We'll be focusing on mobile, and the login process could be something like PayPal's mobile app where they let you login with your phone number and PIN (min 4 digits). I'm just looking for a secure way to translate that to a web app.
Something that could help - sessions could persist for an infinite amount of time, so upon first login we send them 4 random digits via SMS and if they enter it correctly they're authenticated. Basically two factor auth without the initial password.
Why would I want to remember a different passcode every month?
If after two failed login attempts, I must respond to an SMS before I log in, it's really easy to DOS.
Users will be confused by this new scheme. Stick with what has already been vetted in the industry.
This way you wouldn't need to remember a different passcode each month and the login attempt issue wouldn't exist because passcodes are generated when you need to login.