[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 469
  • Last Modified:

Hardware tokens

Hello all,

I'd like to know which of these you prefer and why
- CryptoCard
- Safeword
- Secure-ID
- Some brand I might have forgotten to mention

Few restrictions:
I am only looking for info about hardware tokens. So no USB, phoneintegrated, whatever kinda stuff.


Cheers for your time
1
kneH
Asked:
kneH
  • 14
  • 7
  • 3
  • +2
2 Solutions
 
chris_calabreseCommented:
SecurID is more expensive than the others and the crypto behind it is broken and reversible. On the other hand, it is also more widely used so more admins have familiarity with it, there are webserver plug-ins for it, etc.
0
 
ahoffmannCommented:
> .. there are webserver plug-ins ..
keep in mind that a secure 2-factor authentication is reduced to a 1-factor authentication in context of HTTP
0
 
ViRoyCommented:

how about using a hand?
http://www.biometrics-101.com/hand-recognition.htm

we used hand recognition for access to our server room. it doesnt use fingerprints.
0
 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 
kneHAuthor Commented:
Well biometrics would be going a bit overboard... not so much security wise but budget wise LOL.

As for admins knowing the stuff.... ours are like a blank sheet of paper in that area :)

I know RSA is more expensive... but if it's better it might be worth it... but is it??

>>crypto behind it is broken and reversible
I am completely lost as to what you mean with that... could you please explain?

>>keep in mind that a secure 2-factor authentication is reduced to a 1-factor authentication in context of HTTP
Good thing to keep in mind indeed. But when we get the tokens we'll get an authentication server in the DMZ which should provide a safe connection to it (won't it?)


But getting back to my main question LOL.
Anyone got any prefs?
0
 
ahoffmannCommented:
> ..  which should provide a safe connection to it (won't it?)
hmm, what does a safe (SSL or whatever) connection help if the client or server is compromised, somehow?
A safe connection just makes MITM attacks hard/impossible (with current technology).

> ..  getting back to my main question
I'd go with RSA SecureID 'cause it's widely uses/accepted and a lot of tools/applications and servers support it.

If you just care about the security of a token (wether it is hard- or software), and you need remote access (means not restricted to your building and your LAN), then I don't see an advantage of a hardware token. Simple public keys (PGP, GnuPG, X.509) with a proper pass phrase for its usage would work the same way.
0
 
kneHAuthor Commented:
I know RSA is accepted/known more widely (well that people know of anyways apparently SafeWord is used more but their marketing is crap.. so I read). But it's also a helluvalot more expensive.

SafeWord and CryptoCard can work with each others servers & tokens as well as with RSA's. So the support should be covered with all of these three.

We do need remote access. Remote access to our citrix environment even. So we want to secure that. If the tokens would offer nothing extra over a public key why are they so widely used?

All three of the tokens are widely used. So that's not gonna be the reason to choose for one.

Got any more?
Sorry to milk you for info... But I need to be sure.


For instance CryptoCard and RSA use time dependent keys. SafeWord uses event dependent keys. With time dependent keys the chance of a possible hack is under one in a million. With the event dependant one it's one in over a million.
So that's better. (but then again the calculation came from the safeword website).

It's stuff like that I'd like to know. Real differences in the product rather than the companies.
If at all possible.

Sorry if I wasn't clearer before.

0
 
softplusCommented:
"Can't get fired for using ... " RSA :) They're used most often, but that doesn't mean the others aren't as good.

I'd go with whichever one is easier to integrate with your production system, i.e. the one where YOU can't do much wrong and where things are unlikely to go wrong because one of the admins pushed a wrong button in Exchange (for example) somewhere in the system :). The money you save on tokens might well be more money you'll need to spend implementing it, but you probably know that already. If implemented correctly, they will all work enough for your purpose (unless you have things that need to be *really really* secure - as in government, etc, but in that case you probably wouldn't be asking here :)).

John
0
 
kneHAuthor Commented:
That's what I reckoned... they'd all do about the same.

The only differences I could find where:
- SafeWord is event dependant not time like Secure-ID and CryptoCard
- SafeWord is said to be more robust (harder to break)


We do need to secure our data properly though. I work in healthcare and we have patient information which is confidential. If we get a leak we get a fine. For some reason we don't like to be find hence security is important.


>>(unless you have things that need to be *really really* secure - as in government, etc, but in that case you probably wouldn't be asking here :)).

What kind of authentication would you advise then? (just out of curiousity)
0
 
kneHAuthor Commented:
>>- SafeWord is said to be more robust (harder to break)

Physically I mean.
0
 
ahoffmannCommented:
> If the tokens would offer nothing extra over a public key why are they so widely used?
marketing makes you believe that it is a n-factor authentication (where n>1) which is much more secure than a 1-factor autentication (which is true).

This is just half the truth: in fact there is a n-factor on the client, but as soon as it is transmitted to a remote server somehow it becomes a 1-factor. That's the point why I argue that a good key is as good as a hardware token. Keep in mind: I'm not talking about the security of the line/connection, just the token itself.
So we're back to marketing: their legal intension is to sell something :-)

I also do not blame any of the vendors of hardware token, years back when these technologies where developed they were state of the art and a great security improvement. Nowerdays we look at things in more different ways. As long as the token never leaves the client, it's n-factor, but if it goes over one wire it's 1-factor, hence no longer an improvement. IMHO.
0
 
softplusCommented:
>What kind of authentication would you advise then? (just out of curiousity)
I wouldn't advise in that case :) - you'd need a consultant to look at your whole system before offering any "securer" advice. Sorry.

As ahoffmann wrote, at this level (and above) you're really on a thin line between adding "real security" or just putting a unneccessarily strong link on your already weakend chain... There are many things that need to be taken into account if you feel that you need the full security offered by these systems; just patching something like this over an unsecured HTTP-line will help a bit, but it will not offer you everything it could.

If this is covered, take your pick :). In a hospital-environement the SafeWord-Tokens might actually do a small bit better (I suppose they'll certainly get wet somewhere along the way), but I assume the users are going to take care of them anyway.

John
0
 
kneHAuthor Commented:
Good point there.

So really their entire selling point is crap?
2 factor authentication of which one is strong and one is piss poor...

Kinell cheers man.... I'll slap some people with that arguement.

This is stuff I was looking for!

Time to devide the creds.
Will give most to mr hoffman and a few to softplus for confirming my research so far (though I'd have rather gotten proven wrong (is this a proper sentence LOL)).

Thanks to all who participated.
0
 
kneHAuthor Commented:
Sheesh... why must ahoffman have made a point :(

 Top 15 Yearly  Security  
  richrumble  71990
  SheharyaarSaahil  70035
  ahoffmann  37159
  kneH  30985

Getting away from me there ;)


Anyways just fyi... it's a mental healthcare environment... unless you mean drool the tokens won't get that wet ;)
 
0
 
softplusCommented:
Thanks-  it'd still be interesting to see what you finally implement and why :)
0
 
kneHAuthor Commented:
Well we contracted a consultancy agency.
And basically my job atm is to make their job as hard as possible.
Explain why we should choose for .......

In their initial suggestion they stated we should use RSA. Expensive buggers. Hence the question.

ahoffman just shot a big hole in that.

The only reasons left imo to use a token are:
- to be sure our users use complex passwords and make sure it gets changed often.
- Also they tend to give passes out + write em down (those people really exist)
- And lastly.... by the use of tokens we make sure we don't get the hassle bout them loosing or forgetting a complex password (cos they will).

But at least we won't need one to provide the "extra" security as ahoffman stated. So basically.... seeing the arguements left to choose a token: "cheap is good". LOL

If I am not mistaken CryptoCard is the cheapest one. Then SafeWord. Then nothing for a long time... and then Secure-ID LOL.

SafeWord does integrate well in AD (others integrate too but not as good (so I read)) + safeword tokens are more robust.

Basically RSA is out of the running (at least that's what I'll plead for....) and we should go for either of the other two.

But lets see what our consultant friends have to say bout it all.
0
 
ahoffmannCommented:
> ahoffman just shot a big hole in that.
dooh, don't tell them that it was me 'cause then my profit sharing falls down ;-)

> SafeWord does integrate well in AD ..
dou you mean you want to use authetication against your AD (in LAN) over internet? Hope you know what you do!

To give you another point of discussion with your consultant friends:
  what are the costs of rolling out token, and building the proper servers for them?
  in contrast to simply install something like GnuPG and every remote client gives its public key to the server
  (the private key on the client still needs to be protected by a pass phrase, but that's teaching people)
Both, token, and public keys, are some kind of a PKI. You have to mange it, somehow.

> .. why must ahoffman have made a point ..
'cause I need to make it here without any clue (in contrast to other experts) about M$ :-))

Thanks and good luck.
0
 
kneHAuthor Commented:
>>dou you mean you want to use authetication against your AD (in LAN) over internet? Hope you know what you do!

SafeWord has the option to integrate the key in the AD control panel with a certain user without changing the scheme in a way MS does not support. (LOL I'm happy now... MS says it's safe LMAO)

Anyways it's said to be simple, easier, randomotherwordwhichtheyalwaysuse etc...

as for GnuPG.... some wiseguy decided we are gonna go (don't laugh) completely microsoft.. So might need to look into PGP.

As for the integration with AD... (this just popped to mind) we need to authenticate to citrix servers. So before you even reach the AD you will already have to be authenticated. Sheesh... Looks like I finally woke up LOL.

SafeWord, CryptoCard and Secure-ID all have citrixauthenticationtokens (use that for scrabble!) so you'd think that'd be secure.
But again lets see what the other blokes say.
0
 
kneHAuthor Commented:
Now I'm even more confused seeing the safewordforcitrix.com site says the AD integration is still a good thing.

pffff

I need to get away now.
Enough work done.
0
 
kneHAuthor Commented:
ahoffman...

this one's for you ;)

http://www.rsasecurity.com/japan/images/secured/iPass_screenbig.gif

That will make it two factor :)

Will be useless though seeing our users use various ISP's and I don't think RSA has an agreement with them all... but the idear would be correct.
Except if they have a package sniffer between you and your ISP....
0
 
ahoffmannCommented:
no, see where the client is! only one connection to the service provider, hence 1-factor
even if you improve the topology in that way that the client connects through the service provider to the remote site *and* connects through the clearing provider to the remote site (2 connections) it's hard to say that it is 2-factor 'cause the culprit still is the single client (and no server has any control over it which makes it manipulatable in many ways)

I'd repeat: nice marketing picture ;-)
0
 
kneHAuthor Commented:
Nah... there's one line.
Only they depicted two to make something clear (or I am missing something LOL)

First you go to the network service provider
He sends your signal through a secure line to the company.
Through that secure line you authenticate.
Hence the authentication being invisible (encrypted) from the outside network.
If that authentication would be 2 factor you'd have strong authentication wouldn't you?

So I figure if the NSP sees you are gonna conenct to a certain VPN it would first encrypt that line BEFORE you authenticate.
Making it really a 3-factor authentication fo which two remain intact.

Or do you see this differently?

A picture says moer than a thousand words they way... but I think we're gonna neer more than just a measily 1000 words LOL
0
 
ahoffmannCommented:
whatever secret, password, hash you need to get in on the remote site comes from the client, or in more detail: the user at the client initiates all other factors (be 2 or 3 or ...) but simply giving a username-password pair over one connection, hence 1 factor.
If you control the client, you control the connection, doesn't matter how many factors you add, visible or not, encrypted or not, syncronos or not, based on the first one send by the client.
0
 
kneHAuthor Commented:
I don't get it....

If the client has to authenticate at the ISP, if positive gets a secure line to a server. If not gets blown off.
If you have the secure line you can enter a pin + use a token (hence have two factors left) to send over a secure/encrypted line. that would go against people being able to sniff out your plaintext pin arguement you made...

So that way you'd have 2 secure factors left no??

I agree with you on the part of loosing a factor whenever the client does any authentication over a non secure line. But it wouldn't render all factors insecure.

right? LOL
0
 
kneHAuthor Commented:
http://www.schneier.com/essay-083.html

I get your point now ;)
0
 
ahoffmannCommented:
kneH, thanks for that link, I was waiting for such statements for a long time ...
0
 
kneHAuthor Commented:
That sneider bloke is terribly paranoid and it is good fun to read.

But he does make points.
Strong ones even
0

Featured Post

A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

  • 14
  • 7
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now