Tag Info

Hot answers tagged

7

Neither is necessarily more secure, but I will give you some opinions and perhaps facts. Host-extract can determine hostnames, which is also possible via virtual host enumeration. DirBuster, skipfish, and fuzzdb can rely on forced browsing, directory indexes, and predictable resource locations to find vulnerable directory structures and other issues. ...


6

It is a general best practice to use two separate key pairs (and hence certificates) for signature vs. encryption. I just refreshed myself on the reasons why: When a key is used for encryption, it's often wise to escrow it so that if it's lost, the encrypted content is not also lost. However, non-repudiation associated with a signature certificate isn't ...


6

There is at least one security benefit of sub-domains. If there is an XSS vulnerability on enroll.mydomain.net it can't be used to hijack a session on admin.mydomain.net. This is due to the Same-Origin Policy. It would also make it easier to move that application to a different server if need be. Isolation of failure is a good Defense in Depth approach. ...


5

Better or worse is relative to the usage of the protocol. SAML has it's place and SWT/JWT/et al have their place. The SAML spec is pretty much set in stone, whereas SWT/JWT are really in their infancy and keep changing. SAML has lots of knobs which makes it fairly complex and that's the enemy of good security, but everyone pretty much implements it the same ...


5

Many have pointed out key escrow as a reason for separating encryption and signature keys. Many have also mentioned that this shared use of keys is fine in this particular case. But nobody has mentioned the cryptographic problems in sharing keys for both signing and encryption If you look at official standards for cryptography, most of them specify that ...


4

In this particular scenario, this technique is fine. You use the same cryptographic key (in this case an X.509 cert) to encrypt-to-self. The sample you mention implements a session token (simply speaking a protected cookie), which is shared between multiple similar web services sitting behind a load balancer. So the 'signature' (in this particular ...


3

From security standpoint, there's not much difference between JWT and SAML token specs; it mostly boils down to supported signing and encryption algorithms (JWT is more limited in this regard; see http://tools.ietf.org/html/draft-jones-json-web-token-10#appendix-A). For this use case, in the end they both just provide claims (with all the necessary baggage, ...


3

Well, more accurately it says that untrusted relying parties pose a risk. If you accept token requests from any RP then an attacker could easily gather a fair bit of information about a user. That is the risk. If you only repond to requests from RP's that you know and trust then the liklihood that an attacker can gather the same information is less likely. ...


3

Can someone look at this code and tell me if different certificates should be used in production code? First, any code that is use for a security function should be designed, design reviewed, implemented, code reviewed, and tested before puting in a production environment. Just because the code came from MSDN does not mean that it is secure. Even if you ...


2

Microsoft Azure uses a Remote Desktop Gateway kind of situation, so when you initiate a connection to your Azure Server your connection is via HTTPS until you hit the Microsoft Server farm. Once you int the network your connection is "proxied" via the Azure gateway server, this ensures that the only people who would be able to see any sensitive information ...


2

Yes and no. If done right it will be, but what you are describing is simply an authentication cookie. I would suggest to not reinvent the wheel. The framework/programming language that you use probably already have a way to manage authentication cookie. I would go with that instead of creating it yourself.


2

Standard DNS tables and Azure are pretty flexible when it comes to helping you test this. I'd recommend the following: Register for a wildcard SSL certificate - this will let you apply the cert to subdomains as well. For help creating the cert check out http://www.andrewdenhertog.com/tips/creating-adding-ssl-certificates-azure/ If you want to test the ...


2

I do not believe this is a very good thing. There are simple programs on the net which can attack, and exploit vulnerabilities is RDP. I suggest they look into secure VPN instead on directly opening their domain up onto the net. If you want the serious truth: Using TSgrinder, an attacker could try a brute-force attack using customized lists of ...


1

The primary ramification is that the security of your private SSL/TLS key is ultimately out of your control. Technically, you could use a wildcard certificate, or a multiple domain certificate (Subject Alternative Name, or SAN, certificate). However; if you use a wildcard or SAN certificate, then the security of all of your servers is tied to the security ...


1

If you want your server to encrypt/sign outgoing traffic, then it needs its own private key. This is normal. What I think you are asking is about the security of having this certificate on a server that is ultimately out of your control. You will simply have to limit the exposure of this certificate and have processes in place to handle the event where you ...


1

Securing by IP is a great first step. It severely limits your attack surface. But, as you point out, the source IP in PAAS deployments has limited trust value. Adding a (reverse) proxy server between the outside world & the inside (local) server will also make things more difficult for an attacker. In business settings, having a reverse proxy separate ...


1

I found a good article that should help you, http://www.windowsazure.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/ In their example they show a Wildcard cert, because of the (*) in the domain name *.contoso.com or www.contoso.com If you want a good deal on a Verisign wildcard SSLGURU(DOT)US is a good site that has it for a ...


1

HRD is done through two different mechanisms, which are used in either passive or active contexts. The passive method will determine the realm based on the username after they've lost focus of the username field. A lookup is done of the username and determines what tenant the username is tied to. If the tenant requires federated auth the site will redirect ...


1

I realize this is an old question and I'm not a security expert by any means. However, my experience with Azure ACS and token types led me to three conclusions: SAML worked more-or-less out of the box. JWT was much more fiddly and I had to rely on blogs to get it working. The size of the cookies was equivalent between SAML and JWT. My demo app passed ~30 ...


1

At the end of the day I don't think really matters, since it's a preference of format. SAML 2.0 is set in stone but is very large and verbose (as XML tends to be). But in my personal preference these days with my own projects. I say try out JWT tokens, which is a token in JSON format. If your client applications span across different platforms, it might be ...


1

There is nothing wrong with this approach. Its important to note that encryption!=authentication. Using encryption doesn't guarantee that the message hasn't been tampered with, however by signing the message you can make this guarantee.



Only top voted, non community-wiki answers of a minimum length are eligible