I had set minRequiredPasswordLength,minRequiredNonalphanumericCharacters in membership section of web.config file. but i need maximum password length also to set. how to set in web.config file?
I think that the default implementations of MembershipProvider does not support this feature. However, you could obtain the same results by validating the password length when the users set/change it.
Edit related to PasswordRecovery control
If you are using a standard implementation of the MembershipProvider class with the PasswordRecovery control you are unable to interfere with the generation of the new password (more precisely ResetPassword - "Resets a user's password to a new, automatically generated password").
If you want to use the PasswordRecovery control I see no other option than creating a custom membership provider deriving from the abstract MembershipProvider class or from one of its concrete implementation (like SqlMembershipProvider);
The other option would be to implement your custom password recovery interface as you could still rely on functionality implemented in your MembershipProvider. When the user wants to reset his password you could use GetUser method to obtain the related information, then ResetPassword to obtain a new password. In this moment you may use the password that ResetPassword returns and call ChangePassword to set a new password that meets your criteria, than email it to the user. There are many ways to implement the corresponding user interface, but the reset password logic would be almost the same.
Also in case you decide that keeping the passwords encrypted instead of hashed meets your requirements, your problem will be solved as users will receive through email their old passwords (that meet the maximum length condition from the moment they were set). For this make the following changes in web.config:
Passwordformat="encrypted"
Passwordreset="true"
Passwordretriaval="true"
You must use ValidatingPassword event. Here you can check maximum length, etc. More info available at:
http://forums.asp.net/t/946218.aspx
Related
Is it possible to store multiple credentials for a given user in Keycloak?
They don't need to be all active/enabled at the same time. The use case for us is rather that we want to store new credentials in advance but don't want to have them active yet. They should be activated/enabled at a later time after some manual user verification.
The Keycloak REST API documentation states that UserRepresentation indeed comprises an array of CredentialRepresentation but in my few tests the GET call wouldn't even return a credentials attribute.
I would say that's impossible to have more credentials for a user.
But you can always implement your own user storage SPI that implements interface CredentialInputValidator, where you can check for the valid password.
Let's say in your DB, you have 2 colums for passwords: pas_col1 and pas_col2, and 1 more column as flag, which tells what column is used for user authentication, so in isValid(RealmModel realm, UserModel user, CredentialInput input) method you can check for your conditions.
Link to SPI: https://www.keycloak.org/docs/3.4/server_development/index.html#_user-storage-spi
Details
I have an activity diagram for Login section designed in Eclipse Papyrus. Now I have to write OCL constraints for the following conditions:
a username must be string and < 8 characters
a password must be numeric+special chars and > 10 characters
a user can attempt maximum up to 5 times otherwise the system will lock the login
My Effort
I already done this in class diagram like this but don't know how to apply constraints in activity diagram. I have read a lot of articles, watched videos and research papers and checked questions like this, this, this and this but none of them provide a proper answer.
Sample of my activity diagram image
This doesn't seem to have much to do with Activity Diagrams. Your new wording is clear, 5 attempts on one form or one attempt on each of five forms is bad, so User_Account::failedAttempts (rather than login::attempts) is a sensible model feature.
The Constraint is most eaaily defined as an upperbound of 5 on User_Account::failedAttempts. Note that a Constraint defines what is valid not how to react to invalidity. You could more use an invariant to upperbound against a maximumAttempts() computed value. You could inadvisedly use pre/ postconditions on operations or just knit your control operations.
You could sensibly have a User_Account::isLocked() operation whose body is failedAttempts >= maximumAttempts().
The Activity provides the Control for the Model. Presumably it has a lifeline associated with creation/destruction of a login. Presumably it makes use of a DataBase::checkPassword(userName, password) operation that return the User_Account and increments User_Account::failedAttempts as a side-effect. The enforcement of the maximum is therefore in User_Account::checkPassword.
(NB you should not do two stage access for User_Account lookup then password validation to ensure that hackers cannot distinguish, possibly just by response time, whether a failure is due to a bad username or bad password.)
You need to clearly identify what is in the Model; what persists for the duration of your system, perhaps being restored from backup following a system restart. Therefore User_Account must have username and password and failedAttempts properties to define the persistent state.
Conversely what is part of the View/Control can be lost and recreated when another user interaction is initiated. The login form therefore also has username and password properties to represent what is entered on the form and which will be correlated with the Model DataBase by perhaps DataBase::getUserAccount and UserAccount::checkPassword.
I would not pollute the persistent DataBase model with transient login content. If you require recreation of in-progress login attempts across a server failure, I would have a separate ViewDataBase of transient viewed state. If nothing else you would recover the server failure by reactivating the persistent DataBase before reactivating the transient activities.
I'm developing an API with Sails, and now I need to securize some variables from an entity. Those variable will be accesed only from Admin or own user.
I have an structure like this:
Employee (contains your employee records)
fullName
hourlyWage
phoneNumber
accountBank
Location (contains a record for each location you operate)
streetAddress
city
state
zipcode
...
I need to encrypt phonenumber and accountbank, to avoid anyone to see the values of this fields in the DataBase. Only the owner or the admin.
How I can do that? Thanks
You are looking for a way to encrypt data so that people with no required access right could not see it.
The solution for that is not Sails.js specific and Node actually comes with tools to encrypt data :https://nodejs.org/api/crypto.html.
The key rule here is to always keep your secret password safe.
As for integration in your Sails.js application, I would use callbacks in Models. The official documentation provides a good example here : http://sailsjs.org/documentation/concepts/models-and-orm/lifecycle-callbacks
Basically you just define a function that will be called each time the record is about to be created, fetched or updated. You can then apply your encrypt/decrypt functions there.
This will encrypt/decrypt your phone numbers and bank account numbers automatically.
Regarding access control, you can use Sails' policies along with authentication to determine if the client has the right to access the resource. If not you can always remove attributes from the response sent back to the client.
I implement QuickFix client and I parse SecurityDefinition message ('d') with many user-defined fields. The service provider wants me not to validate user-defined fields, as he says that they add new fields from time to time and don't want to make us (clients) dependant of this.
Is there a way to cancel validation of user-defined fields for one specific message only?
Thanks...
Take a look at the Configuring QuickFIX page, in particular the ValidateUserDefinedFields parameter:
ValidateUserDefinedFields: If set to N, user defined fields will not be rejected if they are not defined in the data dictionary, or are present in messages they do not belong to.
This does not turn off validation of one particular message of course. It turns off validation for User Defined Fields in messages where they are not defined in the Data Dictionary. If the SecurityDefinition message is the only one they add fields to without prior notification then setting ValidateUserDefinedFields to N is probably good enough for you because:
In other messages, either you defined User Defined Fields in your Data Dictionary and they are validated, or you haven't and they are not validated. In the latter case because you probably won't use those fields there's no harm.
In SecurityDefinition only the User Defined Fields you put in your Data Dictionary are validated, other UDF's aren't which is what you want.
If there's still a use-case that would prohibit you from using that configuration option, please let me know in the comments section.
I need to take a user's email address and somehow manipulate the value to come up with an auto-generated password. I want to make sure that I can re-create the same password whenever a user needs to retrieve their password.
Is there a standard way of doing this? Is this what a "hash" is? I would be greatly appreciative if someone could point me in the right direction! :) Once I know where to look, I can do the research myself.
Thanks!
Sunny
Yes, that's what a "hash" is. However, I would strongly caution against this approach, because it means that someone who's good at cryptographic analysis could potentially generate the password for any user on the system, just by knowing their email address.
Standard practice in the case you're suggesting is to actually reset the user's password with a new, random password when they forget their password. That keeps their previous password "safe," so that someone happens to intercept the email with their password, it will only contain a random password rather than a password that the user very likely uses for every other website they log in to.
After a password reset, users should be encouraged to change their password when they first log in.
A hashing function does do what you're looking for - it takes some input x and generates a digest d that will be the same whenever you give it input x again.
A better definition from wikipedia, that explains this property:
Determinism
A hash procedure must be deterministic—meaning that for a given input value it must always generate the same hash value. In other words, it must be a function of the hashed data, in the mathematical sense of the term. This requirement excludes hash functions that depend on external variable parameters, such as pseudo-random number generators that depend on the time of day. It also excludes functions that depend on the memory address of the object being hashed, if that address may change during processing (as may happen in systems that use certain methods of garbage collection), although sometimes rehashing of the item can be done.
However, if this is for password retrieval, I would advise against it. Instead, I would recommend the approach of sending them a link to reset their password, and then have them reset their password.
If you are doing some sort of password reset system, you should just randomly generate a password to their email and than force them to change it on initial login. If they need to reset their password at some other time, than they can go through the same process again.
Something like the md5 function in PHP would be a good place to start. However, why would you need to recreate the same autogenerated password if the user lost it ? Personally, it would make more sense to just generate a new random one.
A Hash is like a fingerprint. If you have the original value (the password for example), you can get the fingerprint and compare to the one you have in your database. But with the fingerprint you have in the database, you can't recreate the original value (you can't create an human from a fingerprint).
It seems to be what you want. But even so it could be not what you need. Generating a password from the hash of an email address means that anyone that know how you hash your email address will potentially know every password.
If you're looking to a password recovery system, you should instead use a Self-service password reset system.
The users says that he forgot the password
You send a unique key (that you store in your database) to this user by a secure mean (usually mail).
The user confirm that he forgot the password by giving you the unique key previously used. This way you're sure that the user is the owner.
You generate a totally random password that you store (in the hashed form) in your database and send it to the owner by the previously used secure mean.