[THIN] Re: Securing MFXP

I can't revoke the second factor. I can disable is account in ADS. In security, 
the biggest risk is always the human factor like your doctor. There's nothing 
that we can do about that... just make their life harder.

 

The fact is that here in quebec, the hospital is running partially in a private 
network regulated by the government and they don,t allow the use of public 
certificate, and since we don'T own that domain, no Public certificate company 
will allow us to get a certificate for a domain that we don't own. We cannot 
access internet and that setup is strictly for internal access between 
hospitals via this private network. Slowly, we are implementing the secure 
computing but meanwhile, they use that private certificate.

 

  _____  

De : Joe Shonk [mailto:joe.shonk@xxxxxxxxx] 
Envoyé : 17 août 2005 18:03
À : thin@xxxxxxxxxxxxx
Objet : [THIN] Re: Securing MFXP

 

What government regulation is that?  I'm currently at a hospital and have built 
WI/CSG for many other hospitals.  And even then a private root can't be 
considered second factor.  You'd be surprised what people do... One guy put his 
securid token on the web via a webcam.  There is nothing that is preventing 
doctors and nurses from copying the private root ca or posting it to a website. 
 Also, how do you revoke this "second factor" after the user's employment has 
been terminated?

 

Joe

 

  _____  

From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of 
Marc-Andre Lapierre
Sent: Wednesday, August 17, 2005 2:38 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Securing MFXP

 

For sure this is the best. Actually, I use a combination of CSG + Secure 
Computing Safe word for citrix or premiere access. I was just talking about the 
situation of ILMS (original post) which include only the use of Certificate.

 

But I've got some customer (hospital) that couldn't use a public certificate 
since the government does not let them do that. I had to do it that way + they 
required two factor authentication and the cheapest way possible. The 
combination of a private root + username password met their needs. It's not the 
best, I agree.

 

Another cool solution I use: RadIIS on the WI + a radius server that holds a 
second user database. You got to authenticate to the radius first with a 
username + a java passcode generator (kind of soft token + PIN) that change on 
a daily basis and give you the WI login page then after you authenticate to 
your ADS through the WI to get your Ticket and your icons.

 

 

 

  _____  

From: Steve Greenberg [mailto:steveg@xxxxxxxxxxxxxx] 
Sent: Wednesday, August 17, 2005 5:32 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Securing MFXP

 

I tend to agree, but rather than target the CERT for improvement, I would use a 
third party security add on such as Secure Computing and require another factor 
of authentication to gain access...

 

Steve Greenberg

Thin Client Computing

34522 N. Scottsdale Rd D8453

Scottsdale, AZ 85262

(602) 432-8649

www.thinclient.net

steveg@xxxxxxxxxxxxxx

 

  _____  

From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of 
Marc-Andre Lapierre
Sent: Wednesday, August 17, 2005 2:02 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Securing MFXP

 

What if you use Entrust Authority?

 

Right now, the weakest aspect of a CSG setup is the username/password... If you 
use a private Cert that you don't give, the hacker has to find the 
Username/Password + hack/fake or whatever your private CA certificate, which is 
not that easy even with MS technology. If you use the public one, yes your 
encryption might be stronger, but anyone can get that CA certificate and the 
only wall they have in front of your network is, in most cases, a 
username/password to find. The hacker that has the knowledge/ability to break 
in a Microsoft CA certificate is probably able to break in a Thawte/Verisign 
one... While a username/password guess/try is easily feasible to anyone. Maybe 
I'm wrong, but if I have to choose, I prefer having a slightly week encryption 
(specially knowing that the content of an ICA packet is almost useless) with an 
easy to create and a private MS CA Cert than having a stronger encryption but 
easier to break in a Username Password only!

 

  _____  

From: Bray, Donovan (ESC) [mailto:BrayD@xxxxxxxxxxxxxxxxxx] 
Sent: Wednesday, August 17, 2005 4:29 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Securing MFXP

 

From a security standpoint I don't think what you are suggesting is entirely 
true. I guarantee you Thawte and Verisign run a much more secure CA, than the 
rest of us can.

 

What you are suggesting is potentially more hoops for an attacker, but if the 
hoops are easier to get around, there's no security advantage. Also as stated 
before it increases your training costs, and ongoing TCO for additional 
helpdesk calls, that you could have reduced by paying $300/yr to a reputable 
publicly available CA.  I wouldn't consider anybody's self setup CA to be more 
secure than a reputable public CA, unless you are in the business of setting up 
Certificate Authorities and you had a considerable amount of money to invest in 
the PKI infrastructure.  Setting up a secure CA and PKI infrastructure is well 
beyond running just running Microsoft's CA software on a single box. It's about 
the business practices of the CA as much as it is about the technology.

 

  _____  

From: Marc-Andre Lapierre [mailto:malapierre@xxxxxxxxxxxxxxxx] 
Sent: Wednesday, August 17, 2005 1:00 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Securing MFXP

But using a private cert is more secure than using a public one since the ICA 
has to trust the Root certificate of the CSG box. It's a king of two factor 
authentication since you need to give the private certificate to your users.

 

  _____  

From: Joe Shonk [mailto:joe.shonk@xxxxxxxxx] 
Sent: Wednesday, August 17, 2005 1:26 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Securing MFXP

 

I would look at using CSG; it's more secure and free with your SubAdv.  It's 
much simpler to setup and maintain than SSL Relay, even with 2 servers.   I 
would also look into using a Public cert.  They can be had for only $50 dollars 
and saves a bunch of time and hassle trying to teach end users how to install 
the root cert.

 

Joe

 

  _____  

From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of 
ILMS (Air)
Sent: Tuesday, August 16, 2005 9:24 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Securing MFXP

 

Hii friends!

 

We have 2 MFXP FR3/W2k3 servers, users logging in using WI over LAN/WAN.

Would like to implement SSL.

 

What I have in mind is:

 

1.  Setup CA on one MF server. Create root cert.

Issue Server cert to both MF servers (IIS servers) and install through IIS.

 

2. Direct WI to use HTTPS (or Citrix SSL??) on 443, also set MF server name 
same a certificate name.

 

3.  Setup citrix ssl relay on both MF servers (required??).

 

4. Install root cert on clients.

 

5.  Open only 443 port.

 

6.  Direct users to use https://server

 

 

waiting for your feedback!!

thnx in advance!

Other related posts: