I'm creating a Rails 3.2 app at the moment and I'm trying to make it so that it's as simple as possible for a user to log in, preferably only using a 4 digit-code.
I was thinking about creating a subdomain for each user, and then just limiting the password to four digits and make it numerical only (which I guess would work).
However, I don't really need such a complicated set up, all the users will see roughly the same thing, and there's no private information between users, it's simply to save time logging in, so they don't need to bother with a username.
Does anyone have any suggestion about how I could do this and then implement it?
Any help is greatly appreciated.
Why not just use there email address on login? I wouldn't not limit how complex the password is. This should be very easy with devise.
Another point that is should be made is that a 4 digit number is not secure at all. There is only 10,000 passwords to choose from. Very easy to crack with the proper software.
The solution: Just use email and password. Simple to do and a Internet standard.
Related
I have a php site with several thousand users that is using PHPass for password hashing. I've written a new Rails site that is using Devise for authentication. I'm trying to seamlessly migrate users over to the new rails site. Does anyone know a way I can migrate their passwords over to the new site?
I originally thought it would be as simple as copying a salt over, but clearly it's not that simple.
I found this question/answer, but I can't figure out what my PHPass salt is, and how I would use that to translate the passwords into something Devise can understand.
Any help is really appreciated!
Reading the code, it seems to encrypt the the salt and the hash together. So you'd have to write some custom code in ruby to mimic their hash, salting, and then encrypting to match to password.
I would take a slightly different approach.
I would use this as an opportunity to clean house. I'd import just the users, and then when you are ready for the switch over, send out an e-mail to your users that you've upgraded the security of you system, and b/c of that you need they will need to reset their passwords, and then provide them with a one-time link to reset their passwords.
Are there some good resources tutorials or anyone has tried to implement a Capcha on devise when user enters x wrong passwords?
The idea is that the capcha shows up on to many requests to prevent bots or other bad guys out and limit the number of requests on the devise signing page.
I can think of doing that in two ways:
The first one is based on failed_attempts attribute (so you should increment it after each unsuccesful login). To use it on Devise, you may create your own FailureApp overriding the respond method to update to do an increment on the failed_attempt attribute on the user. When the user reaches the captcha limit, you may set a the flash attribute to signalize about this and thus, you decide on your controller about the captcha. But there is a problem with this way: as it logs for users, it won't work for an user trying different logins.
The second one is based on the IP: for each unsuccessful login, you keep record of IPs and unsuccessful attempts and when an IP reaches a limit you set the already mentioned flash attribute to signalize that the request number from that IP have already reached the limit and you can show the captcha. You can use ActiveRecord and a relational database or even something lightweight like Redis to do that. You may also think about ways to remove old data from this database.
My co-workers are using a commercial program that encodes and stores login passwords on some database.
Now, I'm developing another program to achieve some other tasks, but I want my co-workers to authenticate to this program with their same username and passwords to avoid confusion.
The problem is, I don't have (and probably never will) any source code to determine which encryption algorithm they've used.
I ran some tests and observed that same passwords always produces same hashcodes with 24 characters in length. For example;
1 XeVTgalUq/gJxHtsMjMH5Q==
123456 0Q8UhOcqClGBxpqzooeFXQ==
Is there any way to determine which algorithm they've used ?
Thanks in advance,
Nope. That is the point of encryption / hashing-- it is supposed to be opaque so that it should not be easy to reverse engineer. The only thing you can do is try a few well-known hash algorithms like SHA-1 and see if the hash values match the other program. But, there's no way to know if the other program added in any "salt" or is hashing together multiple things, e.g. username + password or some other scheme. So you are probably out of luck on that front.
One idea you could try with your new program: if the user has never logged in before, allow them to log in the first time with ANY password. Tell the users that they should use the same password they did with the other program. Then, when they log in, capture that value and hash it using your own hashing scheme, then store that for future logins. So ultimately you would get the result you're aiming for (that users can use their same passwords), without having to reverse engineer the encryption scheme of the other program.
Now, clearly the drawback with this approach is that it is not secure at all for the first login. Someone could hijack another user's account if they logged in as that user before the real user had a chance to log in for the first time (and thereby lock in his password). So this is only an option if there is no sensitive data pre-loaded in the new program that could be compromised. Also you would need the ability for an administrator to reset a users' password so that if this kind of thing did happen, you could correct it easily when the real user reports that they can't log in.
I have an corporate intranet project that needs logins, but doesn't need high security. Impersonating a different user is not useful or very desirable. In similar intranet systems, everyone has the same password as setup by the admin.
I'm hoping to get some suggestions on what password alternatives I could consider. My first thought is to show each user 8 images and have them click on one to be their password. Would this be too annoying or problematic in someway? What other ideas would you suggest?
Why not just use a text based password? It sounds like you are over-complicating things by including images, especially if, as you stated, don't need "high security". I wouldn't consider a text based password "high security" but it does meet your requirements of a login on the intranet. A lot of products have built in functions for passwords so it would be dead simple to implement into your project if you have this available. I'm suggesting you keep it simple and don't assume that impersonating a user isn't something that won't happen without at least a password. You'd want to know who made changes or have some logs that identified who was the user at the time of a certain event.
Remember, security should be baked in, not sprayed on!
I know the title is a little off, but it's hard to explain the problem in a short sentence.
I am the administrator of a legacy webapp that lets users create surveys and distribute them to a group of people. We have two kinds of "users".
Authorized licenseholders which does all setup themselves.
Clients who just want to have a survey run, but still need a user (because the webapp has "User" as the top entity in a surveyenvironment.)
Sometimes users in #1 want us to do the setup for them (which we offer to do). This means that we have to login as them.
This is also how we do support: we login as them and then follow them along, guiding them.
Which brings me to my dilemma. Currently our security is below par. But this makes it simple for us to do support. We do want to increase our security, and one thing I have been considering is just doing the normal hashing to DB, however, we need to be able to login as a customer, and if they change their password without telling us, and the password is hashed in the db, we have no way of knowing it.
So I was thinking of some kind of twoway encryption for the passwords. Either that or some kind of master password.
Any suggestions?
(The platform is classic ASP... I said it was legacy...)
Both options you present sound unattractive to me.
A master password is probably even more dangerous than what you are doing right now
Encrypting (instead of hashing) passwords in the database is not good enough either IMO, as it takes only a break-in on your end to get hold of all passwords. They really should be hashed.
I assume the product, being an old legacy app, is impossible (or not economically feasible) to change in a way that administrator accounts can impersonate user accounts, which in my opinion is still the best approach to this in a real-world scenario (not everyone shares that opinion, discussion on the issue here).
How about introducing a second password column (password2) containing a hashed password that you enter? The login process of the app may be easy to tweak into looking in a second column as well. It might be easy to implement, and I can not see any additional security problems coming from it (correct me if I'm wrong of course.)
What I would do is to let the support staff login with their username/password but to chose a user to "impersonate". So in your session you will have:
logged_user - the actual user who typed in his/her username and password
impersonated user - the user (1) is acting on behalf of
Everything you do is done with the impersonated_user's permissions and preferences.
If you are not impersonating anyone impersonated_user=logged_user.
This way you have to always log any operation with both "actual" username and "impersonated" username; for example:
2010-03-09 | 11:34 am | deleted item #890 | 'George' impersonating 'Lizzie'
sounds like you want to decouple your authentication from your identity a bit. Maybe something like an administrator override page, so that after you log in as the administrator, you have a choice of which user identity you wish to assume. After selecting an identity, you continue to use the app without further authentication.
I like the solution offered by Manrico Corazzi. It reminded me that when you need support from Microsoft, there is way to hand over the control of your machine to a technician. That could be another way to achieve the impersonating mechanism. In order for an administrator account to log in, an authorized license-holders would have to explicitly allow him to join his session and act with all his privileges.