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 ...


4

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

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

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 ...


2

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. ...


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

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 ...



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