I have an C# asp.net app using the default Sql MembershipProvider. My web.config has a few settings that control how I'm using this Provider:
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresUniqueEmail="true"
passwordFormat="Hashed"
minRequiredPasswordLength="5"
The problem I'm running into is that when people reset their passwords, it seems the ResetPassword() method returns a password that is longer than I want and has characters that can be confusing (l,1,i,I,0,O). Furthermore, I'm sending my users an email with a plain-text message and an HTML message (I'm using MailMessage with AlternateViews). If the password has unsafe HTML characters in it, when the email clients render the HTML text the password might be different (e.g. the %, &, and < aren't exactly HTML safe).
I've looked over the "add" element that belongs in the web.config, but I don't see any extra configuration properties to only include certain characters in the ResetPassword() method and to limit the password length.
Can I configure the ResetPassword() method to limit the password length and limit the character set it is choosing from?
Right now I have a workaround: I call ResetPassword() to make sure the supplied answer is correct, and then I use a RandomPassword generator I downloaded off the internet to generate a password that I like (without ambiguous characters, HTML safe, and only 8 characters long) and then I call ChangePassword() to change the user's password after I've already reset it.
My workaround seems kludgy and I thought it would be better to configure ResetPassword() to do what I want.
Thank you~!
ColoradoTechie
I don't believe you can do anything to "configure" the ResetPassword() call. You could write your own provider that changes how the ResetPassword() works.
This link describes the same tactic you seem to be doing already....
Staying with your work around/hack may be the simplest way to go. :-)
However, if you want to learn more on how to create your own provider check out these links.
http://www.asp.net/learn/videos/video-189.aspx
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
http://www.devx.com/asp/Article/29256/0/page/3
http://www.15seconds.com/issue/050216.htm
Using the GeneratePassword method ensures at least that the created password fulfills your setup for MinRequiredPasswordLength and MinRequiredNonAlphanumericCharacters. I am doing something like this:
// aUser is of class MembershipUser
string aTempPassword = aUser.ResetPassword();
string aNewPassword = Membership.GeneratePassword(
Membership.MinRequiredPasswordLength,
Membership.MinRequiredNonAlphanumericCharacters);
aUser.ChangePassword(aTempPassword, aNewPassword);
Well, that's only 50% of what you want since you cannot control the character set used for the final password.
(Actually that's also from my viewpoint the more important aspect - especially if you have users who need 10 minutes and 3 support calls to hit the key combination of a curled bracket successfully and don't have a clue what a clipboard is. ResetPassword can make you one of the most hated persons.)
I know this has already been answered but I wanted to add my 2 cents since I came across this issue today.
The SQLMembershipProvider class exposes
public virtual string GeneratePassword()
which is called by ResetPassword. Therefore you can simply extend the SQLMembershipProvider class and implement your own version of GeneratePassword.
Note that doing so will require you to update the membership provider entry in your web.config to use your new membership provider class:
<membership>
<providers>
<add type="My.Namespace.MyCustomSqlMembershipProvider" ... />
Related
I'm currently using the NLog.Web package for writing my .Net logs in my application.
After reading the NLog.Web I've noticed that unlike the ${windows-identity} layout renderer, the ${aspnet-user-identity} layout renderer got no domain parameter for it.
For example, if I want to log the current running windows identity, it logs out: domain\user, but when specifying domain=false, it logs only user.
How do I implement this kind of ability with the ${aspnet-user-identity}? Because when I configured ${aspnet-user-identity:domain=false} it didn't work.
The WindowsIdentity.Name, used in NLog, will always give the full name, including domain.
The logon name is in the form DOMAIN\USERNAME.
https://msdn.microsoft.com/en-us/library/system.security.principal.windowsidentity.name(v=vs.110).aspx
I think you need a custom layout renderer, and split it by-hand on the /.
Something like this: (maybe also add soms checks for outOfIndex)
using NLog.LayoutRenderers;
....
//register ${my-aspnet-user-identity}
LayoutRenderer.Register("my-aspnet-user-identity",
(logEvent) => HttpContext.Current?.User?.Identity?.Name?.Split('/')[1]);
Register it as soon as possible.
I found a different way to solve this issue #Julian
in the NLog.config file, i created a variable:
<variable name="aspnetIdentity" value="${replace:searchFor=^\\w+\\\\:replaceWith=:regex=true:inner=${aspnet-user-identity}}" />
As defined in the variable, the regex searches for at least one word (at the start) and finally searching for a backslash.
the other backslashes are written to escape special characters and also double backslashing. Finally, what was found (it's the domain name) will be replaced with an empty string and therefore I got only the username and not the Domain\Username
Thanks for the help #Julian
Can anybody tell me how to pass a value from one web form to another web form without using a query string and session?
You can pass the Values over different pages via QueryString like:
Response.Redirect("yourNextpage.aspx?identifier=DesiredValue");
On your next page you can retrieve the value like this:
Request.QueryString["identifier"];
Other Preferred way would be Server.Transer() and Postbackurl.
Refer this link for various possible ways.
there are several ways you can pass parameters between pages.
Using a Query String
Getting Post Information from the Source Page
Using Session State
Getting Public Property Values from the Source Page
Getting Control Information from the Source Page in the Same Application
for more detail visit followng link.
http://msdn.microsoft.com/en-us/library/6c3yckfw.aspx
You could use a Querystring in this case:
Page.Response.Redirect("show.aspx?id=1");
And then read it on the other end:
int id = Page.Request.QueryString["id"];
Using PostBackURL, ex:
PostBackUrl="~/result.aspx"
and on result.cs (Page Load)
lblEmployeeNumber.Text = HttpContext.Current.Request.Form["txtEmployeeNumber"];
With Session:
For example you login the system and your id is 123123123.
string userid = 123123123;
Session["userid"] = userid;
When you go another page/pages your session is alive when your session timeout.
<system.web>
<sessionState timeout="1250"/>
</system.web>
It seems what you're looking for is something like the flash-, view- or conversation scope in Java EE and Ruby on Rails.
For ASP.NET you could perhaps take a look at this one: Is there an equivalent of JSF #ViewScope in ASP MVC?
depends on type and how much information you wish to transfer. for instance, if you want to transfer some variable (strings or integer values) you consider to use querystring (you can found here major information). for instance, if you want to transfer typed objects (class instance) you consider to use session (you can found here major information).
We use Captcha control in a registration form that we make full client validation for all fields in JavaScript ( JQuery ) beside server validation ..
I tried a lot of ways but all will write the Captcha value in JavaScript that can be accessed by anyone :(
I search if is there any way that allow me validate Captcha value in client side using JQuery in secure way or it can't be done ?
It cannot be done.
Javascript is client-side, as you know, and any code client-side has to be treated as potentially compromised as you don't have control over it.
At best, you could resort to sending up a salted hash of the value along with the salt, but even that in itself could be used to test guess values before actually submitting it.
Everything else relies on calls to the server.
As per comment request, here's the general idea:
Firstly, on the server, calculate a random string to be used as the salt. This should be roughly unique every request. The purpose of this string is to prevent rainbow table attacks.
Now, saving this string separately, but also create another string that is the concatenation of random string and the Captcha answer. Of this new combined string you generate the hash (for example, SHA-1) of it.
using System.Web.Security;
...
string hashVal = FormsAuthentication.HashPasswordForStoringInConfigFile(combined, "SHA1");
Both the random string and the hash value need to be placed in the page for the javascript to be able to read.
On the client side, when a user answers the Captcha, take the random string and concatenate it with the answer (getting the idea here?). Taking this string, you can use something like the SHA-1 JQuery plugin to hash it and compare it with the pre-computed hash you sent up.
hashVal = $.sha1(combinedString)
If it matches, it is (almost) certainly the correct answer. If it doesn't, then it is 100% the wrong answer.
you could use ajax to post the current value to the server, which would respond true or false. that would keep you from doing a real post and also from giving away the catpcha's value in html.
My solution )) Every time when page shows captcha to the user, you can dynamically generate obfuscated JavaScript functions(i think the best way 5 or 10).
For example, one function(or 3)) ) can set cookies with pregenerated hash(server returns it)(from real value of the captcha), other functions must realize server side algorithm to check value which user's typed. I can say that it works for 100%, because it is very hard to parse dynamically javascript + we set user cookies on client side(It is very hard for Bots's to find out where and how you set and check cookies), by using JavaScript.
For a Web Application I'd like to generate an email validation link and send it to the user. Like on many public websites, the user should click it to validate his email address. Looks similar to this:
http://www.foo.bar/validation?code=421affe123j4h141k2l3bjkbf43134kjbfkl34bfk3b4fkjb43ffe
Can anybody help me with some hints about the proper generation of those validation tokens? Googling best practices turned out to be more difficult than I though it would be. The links should:
... not require the user to log in first.
... not reveal any login credentials to keep the application secure
... allow me as a developer to efficiently validate the token. I'm pretty sure I need a way to extract the user identifier out of the code to meet this criteria. Don't I?
Furthermore, would you go for a random code, which is saved somewhere, or a generated code which I can recalculate for validation?
Thanks for any replies!
Matthias
P.S. I'm working with ASP.NET 3.5, in case there's an out-of-the-box feature to perform this.
Some suggestions to get you started:
Use GUIDs
Use some sort of salted hash (MD5, SHA1, etc)
Use a random string of characters (the more characters the less likely you'll have collisions)
Store it in a database temporarily, and timestamp it so that it expires after a certain period of time
The simplest way to do it is generate a GUID, store that in the database tying it to their user account and then give them a time-frame within which to click a link with that GUID in.
That validates they are the correct person without making the URL calculable whilst making it resistant to dictionary style attacks.
I construct the hash in a way that can be re-created:
code = MD5( my_hash + user_email + register_timestamp )
Then send a link to http://example.com/validation/?code = 4kj34....
Validation does a lookup like:
SELECT id
FROM users
WHERE
MD5( CONCAT( my_hash, user_email, register_timestamp ) ) = code
AND activated = 0
If you get a single result, update their 'activated' field and sign them in. You can also do some math on their 'register_timestamp' field for a poor man's TTL
I would probably use a Guid. Just create a Guid (by calling Guid.NewGuid()), store it as the validation token for that user, and include it in the validation link.
Is it possible to control the format of the password that is automatically generated by a call to MembershipUser.ResetPassword()?
I want to be able to allow or not allow certain special characters in the generated password.
I am using the SqlMembershipProvider with a password format of Hashed.
Thanks.
You may want to do this in two steps, as identified by Mark Fitzpatrick here: http://bytes.com/groups/net-asp/689452-how-reset-users-password-without-having-use-passwordrecovery#post2740740
First Reset the password, then immediately change it to a format of your liking. Obviously using a fixed string as in Mark's example would NOT be recommended - you'd want to implement some random string generator.
user.ChangePassword(user.ResetPassword(), MyMethodToGenerateRandomPassword());
Today you can also use the Membership.GeneratePassword method and pass a MinRequiredPasswordLengthor use the property already defined in Web.config like this:
var newPassword =
// 0 = Number of non alphanumeric characters
Membership.GeneratePassword(Membership.MinRequiredPasswordLength, 0);
user.ChangePassword(user.ResetPassword(), newPassword);
Have a look at this article - Changing the autogenerated password format in the SqlMembershipProvider.
I came up with a quick way to hack the SqlMembershipProvider to generate less complex passwords, and it was as simple as creating a new provider class that inherits from SqlMembershipProvider, then overriding the GeneratePassword method.
This is not a fully resolved solution but it might help.
I was hoping that there would be some configuration setting could use but overriding the GeneratePassword() method works for my situation.
We already had a crypto utility class that would generate the random password strings so it was a pretty quick change.