I am trying out Umbraco on a test domain right now. I just installed the current release (7.5.8 as of this post). I found Umbraco after trying DNN and what a mess that was. DIdn't work out of the box, Umbraco does. Win for Umbraco.
So, one of my initial changes and customization is to change the default yourdomain.com/Umbraco to log in so something custom for the site. I have two reasons, one is personal, I can't spell umbraco right half the time! The other is added security. If they don't know where to log in, well, they can't :) I know, its not massive security and won't stop someone really dedicated but it will stop common URL probing scripts from reporting a positive potential portal.
I did a search on the subject here and didn't get too many usable results and the vast majority are for much older versions and I discounted those as it appears the url has changed since those older versions.
I don't want to url-rewrite as I don't want it to answer on /Umbraco at all so redirecting/forwarding to it isn't the answer to the security half of my reasoning.
Any kind soul want to point me in the right direction to get the URL changed? I would really appreciate any tips to get me started on this goal.
I appreciate your solution suggestions and they likely would work for many people.
This is mainly for when I wish to log into the site via any mobile device(s).
I do not install bank apps on my phone, tells someone where my money is.
I do not install website apps (paypal/ebay/etc) telling someone I use those services.
I do not bookmark login pages to anything, tells someone where I log into.
Bookmarking it on a secure PC, is one thing. But if a phone is lost or stolen (far more likely than someone breaking into your home to pillage your PC), I don't hand them everything about me in the process. And, yes, my contacts list and call history is really short too :) I have never lost my phone, but its a possibility and its something one must prepare for.
The IP white list is also not a solution for the mobile login as I usually use Tor browser on a mobile so the IP could be coming from anywhere on the planet.
So, I try to not make site logins something that can be guessed at "/admin" or "/login", etc. following the same logic that if someone (hacker) doesn't know where to login, they can't try to guess passwords can they?
I will try the web.config option. If a plugin doesn't install, I presume I can comment out the node in web.config, install plugins as needed and restore it after? The plugins that require it to be the default to use, well I suppose I really don't need those specific plugins ;)
Again, thank you very much for offering multiple solutions and outlining potential drawbacks involved. And for the rapid reply. Makes me happy DNN was a wash and I tried umbraco.
Wow.. tin foil hat alert! And I thought I was pretty cautious.
In this case then I will point out that what you're trying to do is pretty weak and basically security through obscurity. I hope nobody can sniff your DNS queries either, else they'll be able to easily figure out your hidden URL.
One other thing to note then: we do lock out people after 10 attempts to log into the backoffice, this number is configurable on the UsersMembershipProvider's maxInvalidPasswordAttempts attribute that you can add to web.config.
Thank you again. Tin foil hat proudly tipped in your honor :)
I had already found that attribute using the forum search here when I was looking for the minimum password length and complexity requirements setting and its already set to 2 in my web.config. Changed the non-aplha to 6 and minimum length to 24. I also disabled the password reset.
I am already reading up on useLegacyEncoding as to how passwords are hashed/stored. Trying to learn what I can about it.
And, yes, I am fully aware its weak (changing the URL). Its simply one more layer on the onion.
Its a piece of cake to break the window on your car door, but you still lock it right?
There are tons of script kiddies out there with scanning scripts looking at common urls (/admin, /login, /umbraco, etc.). I see them in the server logs all the time. 99% of the time, if the URL doesn't answer or returns 404, they move on.
Same with the guy that runs through the parking lot at the mall lifting door handles. If its locked he moves on quickly to the next one looking for an easy find.
I am unsure right now what the clear difference between the UsersMembershipProvider and UmbracoMembershipProvider node's purpose is. Still have to do some research on those. So for now, I have been mirroring changes until I fully understand their difference.
You will want to set useLegacyEncoding to false (it's sadly still set to true for legacy / backwards compatibility reasons) so the hashing of passwords is quite weak. I'm not sure if you can log in to the bakoffice, set it to true and then change your password in the backoffice (to force an update in the database).. but I'm hoping that will work.
The Users one is for the backoffice login, if you use any membership on the frontend then you want to update the Members one :-)
Right now,its on a testing domain and not a big crisis as to how secure they are currently stored. Its simply a "see how it works" install and not the final run. Don't want to get locked out and have to reset things.
I am replicating changes to a clean un-zipped install so when it comes time to put it on a real domain, I will have these changes in place from the time it runs for the first time.
So I think I will leave the encoding setting alone on the test one on the presumption that setting it to false for the install will have it hash the PW thats entered during the setup wizard in the more secure hash? And then continue to use the more secure hash.
The risk is very low for your test site, if it doesn't work then just turn legacy back to true and you're back in business (maybe copy the password hash beforehand from the umbracoUser table to make sure).
Alter URL for Admin login
Hello,
I am trying out Umbraco on a test domain right now. I just installed the current release (7.5.8 as of this post). I found Umbraco after trying DNN and what a mess that was. DIdn't work out of the box, Umbraco does. Win for Umbraco.
So, one of my initial changes and customization is to change the default yourdomain.com/Umbraco to log in so something custom for the site. I have two reasons, one is personal, I can't spell umbraco right half the time! The other is added security. If they don't know where to log in, well, they can't :) I know, its not massive security and won't stop someone really dedicated but it will stop common URL probing scripts from reporting a positive potential portal.
I did a search on the subject here and didn't get too many usable results and the vast majority are for much older versions and I discounted those as it appears the url has changed since those older versions.
I don't want to url-rewrite as I don't want it to answer on /Umbraco at all so redirecting/forwarding to it isn't the answer to the security half of my reasoning.
Any kind soul want to point me in the right direction to get the URL changed? I would really appreciate any tips to get me started on this goal.
Well, there's always bookmarks, right? ;-)
Try changing this in your
web.configand also rename the Umbraco directory of course:A word of warning: some plugins will rely on the directory to be named
umbracoto be able to either install or use them so.. your mileage may vary!Tip: another option is to set up IP whitelist filters.
Thank you Sebastiaan,
I appreciate your solution suggestions and they likely would work for many people.
This is mainly for when I wish to log into the site via any mobile device(s).
I do not install bank apps on my phone, tells someone where my money is.
I do not install website apps (paypal/ebay/etc) telling someone I use those services.
I do not bookmark login pages to anything, tells someone where I log into.
Bookmarking it on a secure PC, is one thing. But if a phone is lost or stolen (far more likely than someone breaking into your home to pillage your PC), I don't hand them everything about me in the process. And, yes, my contacts list and call history is really short too :) I have never lost my phone, but its a possibility and its something one must prepare for.
The IP white list is also not a solution for the mobile login as I usually use Tor browser on a mobile so the IP could be coming from anywhere on the planet.
So, I try to not make site logins something that can be guessed at "/admin" or "/login", etc. following the same logic that if someone (hacker) doesn't know where to login, they can't try to guess passwords can they?
I will try the web.config option. If a plugin doesn't install, I presume I can comment out the node in web.config, install plugins as needed and restore it after? The plugins that require it to be the default to use, well I suppose I really don't need those specific plugins ;)
Again, thank you very much for offering multiple solutions and outlining potential drawbacks involved. And for the rapid reply. Makes me happy DNN was a wash and I tried umbraco.
Wow.. tin foil hat alert! And I thought I was pretty cautious.
In this case then I will point out that what you're trying to do is pretty weak and basically security through obscurity. I hope nobody can sniff your DNS queries either, else they'll be able to easily figure out your hidden URL.
One other thing to note then: we do lock out people after 10 attempts to log into the backoffice, this number is configurable on the UsersMembershipProvider's
maxInvalidPasswordAttemptsattribute that you can add toweb.config.Thank you again. Tin foil hat proudly tipped in your honor :)
I had already found that attribute using the forum search here when I was looking for the minimum password length and complexity requirements setting and its already set to 2 in my web.config. Changed the non-aplha to 6 and minimum length to 24. I also disabled the password reset.
I am already reading up on useLegacyEncoding as to how passwords are hashed/stored. Trying to learn what I can about it.
And, yes, I am fully aware its weak (changing the URL). Its simply one more layer on the onion.
Its a piece of cake to break the window on your car door, but you still lock it right?
There are tons of script kiddies out there with scanning scripts looking at common urls (/admin, /login, /umbraco, etc.). I see them in the server logs all the time. 99% of the time, if the URL doesn't answer or returns 404, they move on.
Same with the guy that runs through the parking lot at the mall lifting door handles. If its locked he moves on quickly to the next one looking for an easy find.
I am unsure right now what the clear difference between the UsersMembershipProvider and UmbracoMembershipProvider node's purpose is. Still have to do some research on those. So for now, I have been mirroring changes until I fully understand their difference.
You will want to set
useLegacyEncodingtofalse(it's sadly still set totruefor legacy / backwards compatibility reasons) so the hashing of passwords is quite weak. I'm not sure if you can log in to the bakoffice, set it totrueand then change your password in the backoffice (to force an update in the database).. but I'm hoping that will work.The
Usersone is for the backoffice login, if you use any membership on the frontend then you want to update theMembersone :-)Right now,its on a testing domain and not a big crisis as to how secure they are currently stored. Its simply a "see how it works" install and not the final run. Don't want to get locked out and have to reset things.
I am replicating changes to a clean un-zipped install so when it comes time to put it on a real domain, I will have these changes in place from the time it runs for the first time.
So I think I will leave the encoding setting alone on the test one on the presumption that setting it to false for the install will have it hash the PW thats entered during the setup wizard in the more secure hash? And then continue to use the more secure hash.
It's a good theory. Been a while since I tried!
The risk is very low for your test site, if it doesn't work then just turn legacy back to true and you're back in business (maybe copy the password hash beforehand from the
umbracoUsertable to make sure).I found the umbracoReservedPaths when looking at umbracoPath in web.config.
Should I add the new url to umbracoReservedPaths in addition to umbracoPath?
I presume thats used to prevent any created content from absorbing any reserved url?
Ah, yes! Forgot about that, but indeed, it should be added there too!
is working on a reply...