I have active directory and several client computers joined the active directory.
In the client computers I have installed wcf clients.
On the server the wcf service is hosted in IIS.
I use message secyrity with windows credentials.
Everything is working fine.
But I have heard that there are some programs than can extract the password from windows (put live compact disk in the cdrom and restart the pc).
They can use the user and pass to access the wcf service from elsewhere and do damage.
Is this true and what steps can I take to be more safe ?
Regards
Shiraz' advice is all valid for local (not AD) Windows accounts, but I believe the threat you're raising isn't related to the SAM-stored local Windows passwords, since you're talking about an Active Directory setup with Windows systems joined to the domain.
Presumably the message security/windows credentials only allows access to the user accounts you've setup in Active Directory. [All discussion here assumes we're talking about those AD accounts, not local accounts on each Windows client.]
Assuming you've only allowed access to the WCF service for AD accounts, then the WCF service is only practically vulnerable to attackers who can retrieve (or guess) the plaintext password. Since you raised the spectre of live CD attacks, I'll further assume you're only worried about attacks on the Windows clients and not on the AD domain controller (whose physical security is presumably much stronger than the physical protections of the Windows clients).
So the threat you're raising is the possibility that an attacker could somehow find the user's AD password somewhere on the hard drive of the Windows client (or an easily-broken equivalent of their password). That is not the kind of attack for which the Live CDs are generally useful - as Shiraz indicated, they're good for digging up the password hashes out of the local SAM and helping to brute-force try many password combinations (or compare them to a local or online "rainbow table" that contains a ton of pre-calculated password values). Some of these tools also scan through local caches of such passwords, such as older browsers that saved your password for web site authentication - though modern browsers pretty much all have avoided those plaintext backdoors now.
The main cache of a user's AD password on a Windows client is the "cached domain credentials" (which allows you to logon with your domain password even if you're not connected to the network). This isn't stored as just a simple hash of your AD password - instead, it's doubly-hashed and encrypted with the local SYSKEY, making it an order of magnitude more time-consuming to try to brute force. A reasonably long or strong (or both) AD password makes brute-force attacks pretty much infeasible except for very dedicated attackers (like espionage, governments, etc.) So your most effective tool to make sure this is infeasible is to set a reasonable password policy - complex characters and a decent minimum length is fine; non-complex but very long passwords (aka passphrases) are also worthwhile.
Other caches of the password might exist, but that's dependent entirely on whether your users are using really crappy applications - there are fewer and fewer such applications on the market today, but never say never.
This will depend on the version of windows and how updated it is. Previously there was a problem that you could boot the PC using a linux CD, then run a program that did a brute force attack on the SAM file that contained login information.
But the chances of this doing any damage are very small:
It requires physical access to the machine
It does not work with strong passwords
It would require access to your office or that your service is open to the internet
To counter these threats:
Require strong passwords
Encrypt harddisks
Block access to the service from the internet
Protect your offices
Related
I would like to host a password protected static website on a server, and meet the following 2 requirements:
The static website credentials MUST NOT give any additional access to the hosting server.
The hosting must play nicely with other IIS hosted websites
The hosting server is running Windows 10 Pro.
I've identified 4 options:
Host it in IIS with Basic Authentication enabled
Host it in Apache, separate port, secure with .htpasswd file
Host it in Apache in a VM, use a bridged network, secure with .htpasswd file
Develop a middleware/route request authentication application
Option 1:
Evidently, this option requires a whole new User on the computer.
I do not understand the limitations of a new user's access.
When I hit WindowsKey + R, and run netplwiz, I can configure the user to belong to one of these groups:
Users(default): Users are prevented from making accidental or intentional system-wide changes and can run most applications.
Guest: Guests have the same access as members of the Users group by default, except for the Guest account, which is further restricted as described earlier.
IIS_IUSR: Built-in group used by Internet Information Services.
I can not find the following information in any Microsoft docs:
How IIS_IUSR is "used" by IIS
If any of these groups restrict all access, other than viewing the Basic Auth website
An exhaustive list of permissions granted by the user login credentials, and each group
This method seems confusing and annoying at best, and a complete security failure at worst.
Option 2:
This seems more secure to me, because I can understand the limitations of the user access better.
Option 3:
This seems even more secure, because the hosting server is not directly accessed.
I do not know if this creates other security vulnerabilities though.
Option 4:
This one seems the most secure, because I have full understanding and control over the website's access.
This could take a lot of work though.
An organization can adopt the following policy to protect itself against web server attacks.
Patch management– this involves installing patches to help secure the server. A patch is an update that fixes a bug in the software. The patches can be applied to the operating system and the web server system.
Secure installation and configuration of the operating system
Secure installation and configuration of the web server software
Vulnerability scanning system– these include tools such as Snort, NMap, Scanner Access Now Easy (SANE)
Firewalls can be used to stop simple DoS attacks by blocking all traffic coming the identify source IP addresses of the attacker.
Antivirus software can be used to remove malicious software on the server
Disabling Remote Administration
Default accounts and unused accounts must be removed from the system
Default ports & settings (like FTP at port 21) should be changed to custom port & settings (FTP port at 5069
I'm writing a program on Visual studio using C#. My question is, after I publish the app .exe, is any hacker can see my codes like SQL user name , password etc. is it possible? How can I block this in development stage?
You can Encrypting Configuration Information
Part of securing an application involves ensuring that highly
sensitive information is not stored in a readable or easily decodable
format. Examples of sensitive information include user names,
passwords, connection strings, and encryption keys. Storing sensitive
information in a non-readable format improves the security of your
application by making it difficult for an attacker to gain access to
the sensitive information, even if an attacker gains access to the
file, database, or other storage location.
But all you are doing is not making it not easily decodable.
You simple cannot hide a connection string.
You should connect to a service that authenticates the client and service connects to the database. The database whould not even be publicly available. See WCF (Windows Communication Foundation).
Even encrypted files are not safe, hackers can try access main computers to clone source files....
I am faced with a WCF security scenario that isn't particularly well documented online.
I am developing a product licensing service in WCF that will be deployed along with our software (i.e. the service is running on the same PC as the client). This licensing service will be responsible for a number of things related to controlling use of our software and connecting to our remote licensing server for updates, revocations etc. Consequently it's not the kind of service I want spoofed, and I don't really want spoof clients communicating with it either.
As it's running on the same PC as the client can anyone suggest a security policy for this scenario? I'm particularly interested in authentication as most of the other security principles are straightforward. I'm reluctant to get into certificates if I can help it but as mutual authentication is a priority I'm beginning to think I may need to implement a custom 'challenge/verify' scheme between the service and client.
Any ideas? Thanks for reading.
Chris.
My suggestion is that no matter how much effort you put into that, there will be an attack vector that makes all of your effort null and void. One option is to use ILMerge to provide a single dll for your entire application, and store it encrypted on disk and create a loader that hits your service passing in the registration information. On your side, the service will validate the customer information and send back a decryption key. The loader would use the decryption key to decrypt the DLL in memory and load it dynamically.
The shortcoming of this approach is that a determined cracker could debug your application and when the DLL is decrypted, write the unencrypted stream to disk. Your only means of retribution would be to place some kind of marker on the DLL so that you can identify who was responsible for breaking your copy protection and bring legal action if it's found open on the Internet.
As long as you're deploying this software to the client, then you cannot store any kind of key inside it without risking compromise. Even if you use certificates, you cannot hide them from the client while still making them visible to your application. And if you embed the key in the assembly itself then someone will just pop it open using Reflector.
Assuming you don't care about outright cracking (i.e. patching the assembly's code to simply bypass the license checks), then there's one and only one correct way to implement this type of security and that is to mimic the way a PKI works, by using a remote server exclusively.
In a PKI, when a server needs to validate a client via a certificate, it checks that certificate against the certificate authority's CRL. If the CRL reports that the certificate is revoked then it refuses access. If the CRL cannot be contacted then the certificate is considered invalid.
If you want to implement this scenario then you need 3 logical services but not in your current configuration. What you need is a remote licensing server, a client, and an application server. The application server can, theoretically, reside on the client, but the key aspect of this app server is that it performs license checks against the remote licensing service and handles all of the important application logic. That way, "spoofing" the server becomes an almost impossible task because a casual cracker would have to reverse-engineer the entire application in the process.
This is significantly less safe than making the application server a remote server, and may not offer many advantages over simply embedding remote security checks in the client itself and scrapping the local app/licensing server completely. But if you are determined to take this 3-tier approach then the aforementioned architecture would be the way to go.
Again, this is assuming that you aren't worried about "direct" cracking. If you are, then you'll have to read up on techniques specific to that particular attack vector, and understand that none of them are foolproof; they can only slow an attacker down, never stop him completely.
For those in the know, what recommendations do you have for storing passwords in Windows Azure configuration file (which is accessed via RoleManager)? It's important that:
1) Developers should be able to connect to all production databases while testing on their own local box, which means using the same configuration file,
2) Being Developers need the same configuration file (or very similar) as what is deployed, passwords should not be legible.
I understand that even if passwords in the configuration were not legible Developers can still debug/watch to grab the connection strings, and while this is not desirable it is at least acceptable. What is not acceptable is people being able to read these files and grab connection strings (or other locations that require passwords).
Best recommendations?
Thanks,
Aaron
Hum, devs are not supposed to have access to production databases in the first place. That's inherently non-secure, no matter if it's on Azure or somewhere else. Performing live debugging against a production database is a risky business, as a simple mistake is likely to trash your whole production. Instead I would suggest to duplicate the production data (eventually as an overnight process), and let the devs work against a non-prod copy.
I think it may be solved partially by a kind of credentials storage service.
I mean a kind of service that do not need a passwords, but allows access only for machines and SSPI-authenticated users which are white-listed.
This service can be a simple WebAPI hosted under SSLed server, with simple principles like so:
0) secured pieces have a kind of ACL with IP whitelist, or machine name-based, or certificate-based whitelist per named resource, or mixed.
1) all changes to stored data are made only via RDP access or SSH to the server hosting the service.
2) the secured pieces of information are accessed only via SSL and this API is read-only.
3) client must pre-confirm own permissons and obtain a temporary token with a call to api like
https://s.product.com/
3) client must provide a certificate and machine identity must match with the logical whitelist data for resource on each call.
4) requesting of data looks like so:
Url: https://s.product.com/resource-name
Header: X-Ticket: value obtained at step 3, until it expire,
Certificate: same certificate as it used for step 3.
So, instead of username and password, it is possible it store alias for such secured resource in connection string, and in code this alias is replaced by real username-password, obtained from step 4, in a Sql connection factory. Alias can be specified as username in special format like obscured#s.product.com/product1/dev/resource-name
Dev and prod instances can have different credentials aliases, like product1.dev/resource1 and product1/staging/resource1 and so on.
So, only by debugging prod server, sniffing its traffic, or by embedding a logging - emailing code at compilation time it is possible to know production credentials for actual secured resource.
i have following scenario and can't seem to find anything on the net, or maybe i am looking for the wrong thing:
i am working on a webbased data storage system. there are different users and different places and only certain users are allowed to access certain parts of the system. now, we do not want them to connect to these parts from at home or with a different computer than they are using at their work-place (there are different reasons for that).
now my question is: if there is a way to have the work-place-pc identify itself to the server in some way over the browser, how can i do that?
oh and yes, it is supposed to be webbased.
i hope i explained it so everyone understands.
thnx for your replies in advance.
... dg
I agree with Lenni... IP address is a possible solution if they are static or the DHCP server consistently assigns the same IP address to the same machine.
Alternatively, you might also consider authentication via "personal certificates" ... that's what they are referred to in Firefox, don't know it that's the standard name or not. (Obviously I haven't worked with these before.)
Basically they are SSL or PKI certificates that are installed on the client (user's) machine that identify that machine as being the machine it says it is -- that is, if the user tries to connect from a machine that doesn't have a certificate or doesn't have a certificate that you allow, you would deny them.
I don't know the issues around this ... it might be relatively easy for the same user to take the certificate off one computer and install it on another one with the correct password (i.e. it authenticates the user), or it might be keyed specifically to that machine somehow (i.e. it authenticates the machine). And a quick google search didn't turn up any obvious "how to" instructions on how it all works, but it might be worth looking into.
---Lawrence
Since you're going web based you can:
Examine the remote host's IP Address (compare it against known internal subnets, etc)
During the authentication process, you can ping the remote IP and take a look at the TTL on the returned packets, if it's too low, then the computer can't be from the local network. (of course this can be broken, but it's just 1 more thing)
If you're doing it over IIS, then you can integrate into SSO (probably the best if you can do it)
If it's supposed to be web-based (and by that I mean that the web server should be able to uniquely identify the user's machine), then you choices are limited: per se, there's nothing you can obtain from the browser's headers or request body that allows you to identify the machine. I suppose this is by design, due to the obvious privacy implications.
There are choices though, none of which pain-free: you could use an ActiveX control, which however only runs on Windows (and not on all browsers I think) and requires elevated privileges. You could think of a Firefox plug-in (obviously Firefox only). At any rate, a plain-vanilla browser will otherwise escape identification.
There are only a few of REAL solutions to this. Here are a couple:
Use domain authentication, and disallow users who are connecting over a VPN.
Use known IP ranges to allow or disallow access.
IP address. Not bombproof security but a start.