| || || ||1||2||3||4|
| || || || || || || |
Radovan Semančík's Weblog
Thursday, 13 August 2015
There are not many occasions when a CxO of a big software company speaks openly about sensitive topics. Few days ago that happened to Oracle. Oracle's CSO Mary Ann Davidson posted a blog entry about reverse engineering of Oracle products. Although it was perhaps not the original intent of the author, the blog post quite openly described several serious problems of closed-source software. That might be the reason why the post was taken down very shortly after it was published. Here is Google cached copy and a copy on seclist.org.
So, what are the problems of closed-source software? Let's look at the Davidson's post:
"A customer can’t analyze the code ...". That's right. The customer cannot legally analyze the software that is processing his (sensitive) data. Customer cannot contract independent third party do to this analysis. Customer must rely on the work done by the organizations that the vendor choses. But how independent are these organization if the vendor is selecting them and very often the vendor pays them?
"A customer can’t produce a patch for the problem". Spot-on. The customer is not allowed to fix the software. Even if the customer has all the resources and all the skills he cannot do it. The license does not allow fixing a broken thing. Only vendor has the privilege to do that. And customer is not even allowed to fully check the quality of the fix.
"Oracle’s license agreement exists to protect our intellectual property." That's how it is. Closed-source license agreements are here to protect the vendors. They are not here to make the software better. They are not here to promote knowledge or cooperation. They are not here to prevent damage to the software itself or to the data processed by the software. They are not helping the customer in this way. Quite the contrary. They are here for the purpose of protecting vendor's business.
In the future the children will learn about the historical period of early 21st century. The teacher might mention the prevailing business practices as a curiosity to attract the attention of the class. The kids won't believe that people in the past agreed to such draconian terms that were know as "license agreement".
(Reposted from Evolveum blog)
Tuesday, 4 November 2014
The "insider" has been indicated as a the most severe security threat for decades. Almost every security study states that the insiders are among the highest risk in almost any organization. Employees, contractors, support engineers - they have straightforward access to the assets, they know the environment and they are in the best position to work around any security controls that are in place. Therefore it is understandable that the insider threat is consistently placed among the highest risks.
But what has the security industry really done to mitigate this threat? Firewall, VPN, IDS and cryptography is of no help here. 2-factor authentication also does not help. The insiders already have the access they need therefore securing such the access is not going to help. There is not much that the traditional information security can do about the insider threat. So, we have threat that is consistently rated among the top risks and we have nothing to do about it?
The heart of the problem is in the assets that we are trying to protect. The data are stored inside applications. Typically the data of all sensitivity levels are stored in the same application. Therefore network-based security techniques are almost powerless. Network security can usually control only whether a user has access to application or not. But it is almost impossible to discriminate the individual parts of the application which the user is allowed to access - let alone individual assets. Network perimeter is long gone. Therefore there is no longer even a place where to place network security devices as the data move between cloud applications and mobile devices. This is further complicated by the defense in depth approach. Significant part of the internal nework communication is encrypted. Therefore there is very little an Intrusion Detection System (IDS) can do because it simply does not see inside the encrypted stream. Network security is just not going to do it.
Can application security help? Enterprises usually have quite a strict requirements for application security. Each application has to have proper authentication, authorization, policies, RBAC, ... you name it. If we secure the application then we also secure the assets, right? No. Not really. This approach might work in early 1990s when applications were isolated. But now the applications are integrated. Approaches such as Service-Oriented Architecture (SOA) bring in industrial-scale integration. The assets almost freely travel from application to application. There are even composite applications that are just automated processes that live somewhere "between applications" in the integration layer. Therefore it is no longer enough to secure a couple of sensitive applications. All the applications, application infrastructure and integration layers needs to be secured as well.
As every security officer knows there is an aspect which is much more important than high security. It is consistent security. It makes no sense to have high security in one application while other application that works with same data is left unsecured. The security policies must be applied consistently across all applications. And this cannot be done in each of the application individually as this would be daunting and error-prone task. This has to be automated. As applications are integrated then also the security needs to be integrated. If it is not integrated then the security efficiently disappears.
Identity Management (IDM) systems are designed to integrate security policies across applications and infrastructure. The IDM systems are the only components that can see inside all the applications. The IDM system can make sure that the RBAC and SoD policies are applied consistently in all the applications. It can make sure that the accounts are deleted or disabled on time. As the IDM system can correlate data in many applications it can check for illegal accounts (e.g. accounts without a legal owner or sponsor).
IDM systems are essential. It is perhaps not possible to implement reasonable information security policy without it. However the IDM technology has a very bad reputation. It is considered to be very expensive and never-ending project. And rightfully so. The combination of inadequate products, vendor hype and naive deployment methods contributed to a huge number of IDM project failures in 2000s. The Identity and Access Management (IAM) projects ruined many security budgets. Luckily this first-generation IDM craze is drawing to an end. The second-generation products of 2010s are much more practical. They are lighter, open and much less expensive. Iterative and lean IDM deployments are finally possible.
Identity management must be an integral part of the security program. There is no question about that. Any security program is shamefully incomplete without the IDM part. The financial reasons to exclude IDM from the security program are gone now. Second generation of IDM systems finally delivers what the first generation has promised.
(Reposted from https://www.evolveum.com/security-insider-threat/
Friday, 29 January 2010
Quite an interesting scam appeared on Facebook. It was just a matter of time when something like that will pop up, yet I was quite surprised when I have actually seen it. The scam works like this: There is a simple HTML page that promises to provide nude photos in zip file if you click on the button. However, if you click on the button you will see no butts and tits. A link to the tricky page will be posted to your facebook profile instead. If you want to try it go to http://homeslices.org/f2.html (if the page is still around). But you have been warned.
The trick is simple. The page creates an iframe containing pretty standard facebook form to share a link. However the frame is almost invisible, therefore you cannot see it. But the browser still think you can see it and is processing it. The tricky page has a "View" button on the same location as is "Share" button on the invisible facebook page. You think you are clicking on the "View" button but instead you are clicking on the "Share" button on facebook. The iframe is fetched by your browser, therefore it is your identity that is used on facebook to post the link.
This page is pretty innocent. All it does is a bit of humiliation for the victims, amusement for experts and undoubtedly a lot of fun for the author. But imagine that this very same method is used to subvert your Internet banking. I guess that the method could be adapted to subvert many of current Internet banking applications. It won't be that funny any more.
This is the price we pay for flexible presentation formats. There are two basic principles of the trick:
- Mix the content from two sites in one window. Content from facebook is displayed in a page where you do not expect it, it a wrong context, with a wrong URL in the URL bar.
- Create ambiguous display of information. The browser thinks you can see the "Share" button. If has 1% opacity, therefore it is still somehow opaque and ergo visible. Therefore it thinks that if you click to the place where "Share" button is you want to submit information to facebook. But in fact you do not see the "Share" button because if has only 1% of opacity and therefore is almost invisible. You are clicking to that area because you see "View" button that is behind it.
The first problem is a specific problem of HTML. It can be fixed quite easily, if there would be enough "political will" to do it. But the second problem is the
problem. How much opaque something should be to be considered opaque enough? Should 1% grey text on white background be considered visible? Or can a 2pt big font be considered readable?
Probably the most serious implication of this problem is a bit independent from a Web. Presentation formats are very dangerous when used it a legally binding way. For example if you sign a document with a digital signature. If you sign a contract and it contains a paragraph written in light grey text on a white background, should such a text be considered part of the contract or not? Some devices may display that text as well readable while on some devices it cannot be seen. This opens up a huge door to a scam of all sizes.
This problem applies universally to any data format that includes rich presentation features: HTML, Microsoft Word documents, RTF, OpenDocument and many more. But maybe the worst aspect of all of this is that our government as well as many other governments in Europe explicitly allows such data formats for legally binding documents signed by "guaranteed digital signature". I'm really lucky that I have no qualified certificate to create such a signature.
Thursday, 4 December 2008
Ben Laurie is discussing the nature of passwords. He claims:
If your password is unphishable, then it is obviously the case that it can be the same everywhere. Or it wouldn’t be unphishable. The only reason you need a password for each site is because we’re too lame to fix the real problem. Passwords scale just fine. If it wasn’t for those pesky users (that we trained to do the wrong thing), that is.
I can see where Ben is leading us. Using a device that can take password and convert it to some form of more secure authenticator or protocol exchange. Well, that could work. But there's a catch, as always.
The password itself may be very difficult to phish, because it is never shared with anything but the secure device (under Ben's password utopia). However, the device communicates with the rest of the world using some kind of "secure" protocol. This protocol interaction may be vulnerable to man-in-the-middle attacks. And it surely will be, unless two mechanisms are in place:
- The device must verify the identity of the authenticator party, the web site that accepts authentication. Think about the lesson of Needham-Schroeder and compare that with Otway-Rees. If this is not done, following attack is possible: The attacker Mallory can just pretend he is authenticating user for user's usual daily dose of gossip (read: social site). But the attacker will get the authentication challenge from user's Internet banking application feed that to user's secure device and lure user to provide valid authenticator for Internet banking. The user will think that he is entering password to read the gossips, while he in fact will be authorizing transfer of his savings to support Mallory's Luxury Vacation Charity Fund.
- The device must bind the authentication to the actual communication. Think about how certificates are used to generate the session keys in SSL/TLS. If this is not done, then it is trivial for Mallory to just wait while user executes proper authentication and then hijack his (authenticated) connection. The user may not even notice, as Mallory may pretend network failure. Or Mallory can let user do whatever he does and wait for a logout command. He will silently discard the logout, but pretending it happened. When the user leaves, Mallory can easily afford to buy a new house in Mediterranean.
Unless these attacks are prevented, the whole system will still be inherently vulnerable to man-in-the-middle attacks. No kind of secure device can solve all the issues (although it can improve the situation a bit).
I see the solution like this: User is authenticating to his communication device (computer, mobile phone) with any appropriate combination of I know / I have / I am. When the device is persuaded about the user's identity, it will relay that authentication to other systems. That may be strong authentication, not necessarily based on passwords. This forms a chain of authentication that can have quite a lot of links. However, to get a secure system, use must inevitably believe that the device that displays information for him (workstation, notebook, mobile phone) is operating as expected. Failing that all attempts to secure anything are useless. The bad news is that we are far, far away from that.
Monday, 19 November 2007
Trust simplifies our lives. Human lives. Trust is a relationship that is build
on emotions. If you trust someone, you expect him that he will behave in
some specific way without being forced or highly motivated to do so. You rely that the feelings of the trustee will not allow to betray your trust.
Trust applies only to human beings. It makes no sense to think about trusting the computers. Computers do not have emotions, do not have feelings. Computers does only what they are programmed to do.
When you think that you trust your computer, you in fact trust a lot of people: engineers that designed and manufactured the hardware, architects and developers that provided the software, distributors that delivered the computer, network operators that maintain the network you have used to download the software ... and lots of other people involved with creating the thing that you are looking at just now.
We should not trust computers. Firstly, is not the smartest thing you can do. To trust the computers you have to trust the software developers at the very minimum. And that's a very foolish thing to do (been there, done that). Secondly, it makes no sense to trust non-human object.
The correct thinking is: How strong is my belief that my computer operates as I would expect? Belief is not a binary value and does not imply any emotions on the other (non-human) side of the relation. I pretty much believe there will be snow in the winter (there is, usually). But I do not trust the weather to bring the snow. I believe that a stone will fall down when I drop it, but I do not trust the stone to fall. Got the idea?
The consequence of this is that the usage of word trust in IT is all wrong. The names like WS-Trust or Trusted Computing are incorrect (although they sounds great from marketing perspective).
Maybe all of this sounds strange and simplistic, but I believe there is more to it. I will try to follow-up on this topic in the next blog posts.
Thursday, 15 November 2007
HTTPS should stand for "HTTP Secure". But how secure HTTPS really is? And
how secure are the applications that rely on HTTPS?
HTTPS is based on SSL. Based on my basic cryptology knowledge I can believe
that the mechanisms of SSL protocol as well as commonly used cryptosystems
are secure. The problems seems to be on higher layers: in the servers,
browsers and in the applications.
Servers send X.509 certificates during HTTPS connection setup. Browsers use
the Common Name part from the certificate to check agains the host part of
URL (wich is DNS name). The browsers also checks that the server's
certificate is issued by any of the "trusted" certificate authorities
configured in the browser.
Now, if I use the "https://www.mybank.com/" and I see the page and there is
no warning, what does it really mean? Almost nothing. Nothing that I would
really trust. Why I'm considering that untrustworthy? To explian that you
have to know how the X.509 certificates for HTTPS purposes are issued.
Certificate authorities are expected to issue certificates that have Common
Name (CN) property set to the value of the correct host (which is www.mybank.com
in our case). The only thing that the certificate authority can check is if
the guy that is asking for the certificate is an owner of the appropriate
DNS domain (for example by checking RIPE Database). It can request some
papers from the organization stating that it really exists. And that's it.
The certificate is issued.
Now, how difficult is to twist that? You can legaly register a similar DNS
domain, something like my-bank.com, mybank-access.com, mybank.cc. Then you
get the certificate legaly. And how does users know if the correct domain is
mybank.com or my-bank.com? Or I can just pretend that I want to get
certificate for mybank.com and falsificate the papers. How could the CA based
in USA check the papers (that seems to be) issued by the government of South
Uzbekistan? There were approx. 40 certificate authorities pre-configured in
my Firefox. I would bet that at least one of them will issue a certificate
based on some barely readable fax message showing (seemingly) valid legal
document. And this certificate will be "trusted" by the browser. In fact the
browser with default setting will not distinguish between the certificate
from the lousy CA and the most secure certificate from Verisign.
Some banks are asking users to check the fingerprint of the certificate
at the beginning of each access. The funny thing is that they provide
"authoritative copy" of the certificate fingerprint on the page
that is protected by certificate that has to be checked. Or do they really expect users to
remember the fingerprint? And to check it on each access? No. It is just CYA, not a security
Now consider that the prevailing Internet appliction security mechanism is
authentication by passwords over HTTPS channel. How secure the Internet
applications (including Internet banking applications) really are?
The scary thing is that there are "identity systems" (see
post) that rely exclusivelly on HTTPS ... Shouldn't we rather stop the
nonsense, stand back, take few deep breaths and start thinking and talking
how to make it all right this time?
Tuesday, 30 May 2006
In the last posts I've written
about inherent security problems of current information technologies. Today
I want to write about possible solutions.
To make the long story short (a.k.a. "Management Summary"), I can see no
short-term solution at all. If we work really hard, we can have at least
some security in the first half of next decade. But I really doubt that.
And now the full story:
Perimeter security does not work.
Firewalls are not effective. And I believe that they cannot be made
effective and practical at the same time. We should not rely on firewalls
for providing host security. Hosts should be secure on their own. Especially
mobile hosts, because these cannot count on firewalls protecting them. We
should re-engineer the operating system to build security into their network
Workstations are insecure.
Anyone can do anything. Any process can ruin system security. This has to
change. Operating system should not be designed to "just work", but has to
support non-functional requirements also - such as security and reliability.
Some features of multi-level secure systems should be also implemented in the
conventional operating systems. Well, it may be a little bit difficult to
figure out what features to migrate and how to implement them to be usable.
But I believe we can figure it out. Sooner or later. Probably later than
Windows Vista may be heading in the right direction (*). And it looks like
Microsoft is quite alone in the effort. But I'm not naive enough to believe
that the security can be done right anytime soon. It will take a lot of
thinking, designing and testing.
And that testing will be done on real customers, I suppose, like you and me.
I think that first
release of Windows Vista will not be much more secure than the current
operating system. Because for the system to be secure, all must be changed.
The approach, the technology, the people. And that will take a long time.
I would not expect that we will see any widespread secure operating system
until 2010. 2015 or even 2020 are more probable. But at that time, the low-level
software that runs on computing devices may not even be called "operating system"
(*) It's really ridiculous that such a strong oponent of Microsoft approach
like myself states that Microsoft is doing something that is
heading in the right direction. Well, I would gladly admit that I was all
wrong, and that Microsoft is really great technological company.
But I have a strange feeling that somehow the things are not all that ideal.
The time will tell.
Friday, 19 May 2006
I estimate that at least 95% of all workstations used in home and enterprise
environments are insecure. I do not mean insecure like "there's a hole in the
OS". I mean insecure as "not designed to be secure".
Consider a common Windows XP workstation. How difficult is to infect it with
a virus? Teenage kid can do that. How difficult is to steal data from a PC
that is left unattended? Usually as easy as "reboot and insert USB key". How
difficult is to steal a password of a user? As easy as "install a
keylogger" (use virus, if neccessry).
Attacking the workstation is the easiest way to get what you want. The
workstations are the second weakest part of any system (the weakest part is
that thing that usually occupies space between the chair and the keyboard).
Curent workstations were designed for usability, not for security. Any
application can write on entire screen. We need that, because we want
full-screen games and screensavers. Any application can read keyboard. We
need that, as we want all the fancy pop-up thingies and devious keyboard
short-cuts. Most of the applicatons can read and write anywhere on the
filesystem. We need that because we want to make software installation and
maintenance as easy as possible. That means that any application can do
almost anything. Mix that with ineffective network security and low quality
of standard software products ... what do you get? Disaster in waiting.
That's scary. And the most dreadful thing is, that some people try to build
"secure" systems in this environment. They venture to make
legally-binding digital signature on such platforms.
They store classified information. They process personal data in
large quantities. And they have the nerve (or ignorance?) to call
these systems "secure".
This is the last entry from the "all sucks" series. I promise. I will write
more about possible solutions next time.
Thursday, 18 May 2006
To have a "Perimeter Security" you need two things: a perimeter and a
Let's think about the "security" part of perimeter security first. The most
common device to use there is a firewall. Firewall. The word much abused
nowadays. Seven years ago I wrote a paper
(sorry, Slovak language only) providing an overview and evaluation of
network security mechanisms. I tried to make a clean distinction between
"application-level gateways" and "packet filters" there, and especially the
ability to see and understand network protocols. All of these different
shades of gray are called "firewalls" now. The security
industry evolved towards ease of use, not towards security. And nobody really
seems to care much about the distinction anymore.
Back at InfoSeCon conference,
Marcus Ranum had an excellent presentation
about firewalls. He presented the reasons while today's firewalls do not work.
I can agree with him completely. Current firewalls do not enforce protocol
correctness. Yes, they understand some of the protocols (like FTP or HTTP), but
that is primarily to allow them pass, not to restrict them. Yes, the
firewalls can do URL filtering, antvirus and so on ... but those are
"enumerating badness" approaches that does not really scale. Firewalls are
designed to pass traffic, not to block traffic. That's not quite the
right approach for a security device, is it?
One way or another, there's no considerable security in a firewall any more.
Let's look at the "perimeter" part of perimeter security now.
We are at the beginning of the age of mobility. It is a common thing to work
at home, to read your mail anywhere, to browse Internet using a mobile
phone. In a world like this, can you tell where your perimeter is? Does it
only cover the network equipment you own? Does it includes all the portable
computers that your employees use at home? Does it include yor CEO's notebook
connected to some strange ISP in a hotel room somewhere near the end of the
world? Does it include a WiFi network created by misconfigured PC of one of
your employees? Does it includes mobile phones? And what about fridges,
TV sets and toasters? ... Only
one thing about the network perimeter seems to be certain: it does not
copy the edge of your network.
Now we can see that we do not have security. We do not have perimeter
either. Do we have perimeter security?
I'm not trying to tell you to scrap your firewall as an unneeded piece of
old junk. The firewalls are still needed to maintain a minimal level of
protection at the very least. I'm just trying to tell you, that the
protection that the perimeter security approach provides is just that:
Sunday, 14 May 2006
InfoSeCon 2006 conference is over. It
was really great conference with unique atmosphere. The opportunity to talk
in length to other speakers and to share the ideas was priceless. I also
appreciate that the conference was vendor-neutral. That's something that we
cannot see that often in our longitude. It was unquestionably the best
conference I've attended in Central/East Europe.
The presentations and discussions with other attendees provided a lot of
insight and tons of
material for toughts. I will follow up with more in depth meditations later.
Now I only want to present the overall "look & feel".
Marcus Ranum perfectly summarized current state of
information security in two words: "all sucks". That's exactly what most of
the presentations were about (including mine) - at least partially.
Firewalls do not really work, workstations are insecure, it is really
difficult to get the security management processes right ... nothing really
helps. But what is even worse: nobody really know what to do about it.
There was a lot of good presentations focused on methods to get the security
processes right by the "risk managament" folks.
Marcus Ranum talked about
the fallacy of "generation 2" and "generation 3" firewalls, while hinting
about what went wrong and what can be done about it.
There was an excellent presentation by
Vince Gallo describing the promise
and limitations of security system of Windows Vista. But one way or another,
no satisfactory short-term solution seems to exist.
Maybe we should call this the "Security Crisis" ...
(gee, I hope haven't I just created a new buzzword)
Friday, 28 April 2006
All the local news are full of it. National Security Office of Slovak
Republic was hacked. You can look at the hackers's
description of the attack (Slovak only, sorry). The attack was trivial:
The attackers probed the system using a bug in the webmail system. They got
a suspicious username, tried to guess a password and ... it just worked.
There was a "public" SSH connection and the same password worked on several
other systems. Too easy ...
The National Security Office is quite an important organization of Slovak
government. It supervises the use of classified information, it administers
most of the security checks and clearences. It even hosts the national
(root) certificate authority for qualified digital certificates and sets the
digital signature regulations. You can image the panic that started after
The real impact of the attack was minimal. Hackers gained control over
several servers in the DMZ, stolen few gigs of data, could read and spoof
mails and do similar things.
The Office denies that they've stolen any classified information. But the
impact of this actual attack is not that troubles me most.
The scary thing is the fact that the attack was so easy and straightforward.
I would not wonder if it eventually turns out that a teenager
did it. That triviality of the attack means that the failure is quite deeper
than just a "one weak password" problem.
Every system can be compromised. That's the fact that any security expert
knows. The trick is to make the compromise infeasible. To make it difficult,
time-consuming, expensive. To combine systems and procedures in such a way,
that a compromise is either very unprobable or that it's impact is
negligible. The fact that the Office was compromised so easily, that the
attack was not detected and that the attackers gathered quite a lot of
information tells about severe system failure. I'm not talking about the operating
system, not the firewalls or any other technical system, but the "security
system" as an organizational process.
If the system worked as it should, the hole in the webmail interface
would not be there. It would be fixed by regular patching. It the system
worked the public ssh access would not be there. Would be limited to some
IP address range, would use public-key authentication only, or it just would not be
there at all. If the system worked the user with the weak password would
not be there. It would be detected by regular audit and deleted (or at least
the password would be made stronger). If the system worked the same password
would not be used over several systems. Any of this could hinder or at least
limit the attack.
It is not a failure of system administrators. Considering organization like
this, the security system should address even the deliberate attempt of
a system administrator to lower the security level of the system, not to mention
common unintentional mistakes. The multi-level security and separation of dutties
principles are good just for that.
The fact that all of the weaknesses
existed in the system is a yelling evidence that no effective security
system was in place. And that is the thing that really troubles me.
This attack was just a fun. The attackers had no real intention to harm.
The next attack might not be that friendly ...
Do not look for the www.nbusr.sk webpage
for a while. It looks like it was torn down as a mean to secure the agency.
In fact, all the agency looks to be disconnected from the Net.
Monday, 27 February 2006
Bob Blakeley, one of my favorite bloggers, recently
blogged about the evil nature of passwords:
Static passwords are an unacceptable hazard, good alternatives exist, we
should get rid of static passwords in favor of those alternatives, and we
should do it fast.
He also issued a call for action:
I believe that this community should commit itself to achieving the goal,
before this decade is out, of providing every computer user with a strong
authentication device and the infrastructure required for its universal
While I can understand Bob's motives, I'm afraid that he is too optimistic and
maybe even partially wrong. I think we just can't get rid of passwords. Not
in a soon
future. The reason is quite simple, but the explanation is quite long.
Here it goes:
(for all of you impatient readers, you may skip
directly to the point)
It is a common knowledge that we have three types of authentication:
- Something you know: passwords, PINs, ...
- Something you have: tokens, mobile phones, ...
- Something you are: biometrics
Another (but not-so-common) knowlege is, that just one type of
authentication is not enough. Why?
- Something you know: can usually be easily compromised. See all
Bob Blakeley's arguments.
- Something you have: can be stolen. Even if we accept Bob's
requirement that the theft has to be quickly noticed, "quickly" may easily
be several hours. Consider that you are asleep in a hotel and that one of
the hotel employees steal your device. You will detect that in the morning
at the earliest. And that may be too late.
- Something you are: There is nothing about you that one device can
read and the other cannot. You leave you fingerprints all around you, and it
takes just a few
gummi bears to exploit that. A little more effort is paid to iris, and you even
leave lots of your DNA around. It seems that once you get inexpensive biometric reader
device, there are only few steps that lead to the inexpensive method to fool that device.
Using only one type of authentication is a risk. It does not matter much
which one you choose. The first one (passwords) is the most frequently used
in digital world and hence the attacks agains it are the most advanced. But who
can tell that the other two are more secure? We did not tried that on the
same scale, yet.
So called "two-factor" authentication can address the vulnerability of
single authentication mechanism. You just have to use two types of
authentication to lower the risk of breaking one of them. For example
combine tokens and PINs
or biometrics and passwords. Now, you have three different combinations
authentication mechanisms, and only one does not involve passwords: tokens
+ biometrics. And how would we implement that? Putting fingerprint reader
in your notebook does not help much. As Bob correctly said: the workstation
is not secure. And even if it was, fingerprint authentication is not. And I
can't really imagine portable token with DNA analyzer being affordable
anytime soon. And I don't even dare to think about consumer acceptance.
Well, what we have left? Tokens + passwords and biometrics + passwords. I
will not ponder about the feasibility of these in detail. All we need to
know is that they both involve passwords. May they be in form of PIN,
passphrase or whistled-morse-code-signal, these are still passwords.
(There is another issue while using tokens for authentication, and that is
the number of tokens needed in day-to-day business. Just recall how many
keys are on your keyring. Why do you think that you will not have that many
tokens? But more about this later. Maybe.)
One way or another, we cannot get rid of passwords anytime soon. But the one
thing that we can change is the way how we use and manage them.
First of all we need to get rid of one-factor password-only authentication
for all important transactions. We should use two-factor authentication instead.
And make sure that we enter our passwords into secure devices, not into our
workstations. We shoule have the secure device do the "strong" authentication,
not your notebook.
We have to assume realistic goals. We cannot get rid of passwords, but we can
change the way that we use them. This should be the goal of the decade.
Friday, 18 November 2005
I've recently found Dan Blum's Identerati blog and found
that explains why "strong" authentication will not fix phising. And it
really struck me. How anyone could ever think that one-way authentication
can fix a man-in-the-middle attack? What kind of people are out there?
Some environments can really surprise me. It is only few years ago that I've
learned that some American bank did use only simple passwords for Internet
banking access. "What a foolishness", I tought. Here, in the barbaric eastern
europe no bank would ever risk that. Even the technologically least
advanced bank deployed at least some kind of "strong" auth before the break
of the millenium. And even with strong auth there were some braches. Nothing
public, of course :-)
Only later I've learned that it is common practice in the US to use passwords
only. Real foolishness. I'm no fan of so called "strong authentication",
because that is usually just a one-way dynamic password authentication
scheme(*) packaged in a nice box. But even that is much better than static
(*) Oh yeah, you can "secure" the "strong" auth by wrapping the HTML form in
SSL. But, have you ever seen the list of "trusted" Certificate Authorities
in your browser? No? Then go on and have a look. I would bet that there
are many of them that you've never heard of. Do you trust them? I'm sure you