The WiKID Blog, musings on two-factor authentication, information security and some other stuff.
How can a software token be as secure as a hardware token?
Posted by: root 16 years, 4 months ago
Simple, really.
There are two factors: possession of the private key and knowledge
of the PIN. The private key is stored on the client. Our PC client, for
example, this key is in a password-protected PKS12 encrypted file. If
someone steals this file and brute-force attacks it and gets the
passcode, they are only half-way there.
They still need the PIN. The PIN is stored encrypted on the WiKID
server. Losing the private key is the equivalent of losing a hardware
token. You're only half-way there.
Typical software tokens store the PIN, the secret and the algorythm all in the client. Clearly this is not the way to do it.
But we can't ask non-employees to run software on their PCs. What can we do about vendors?
Posted by: root 16 years, 4 months ago
We suggest you use USB tokens or wireless tokens.
How are users provisioned? How is initial validation handled?
Posted by: root 16 years, 4 months ago
A big problem with hardware-based tokens and
traditional soft-tokens is the need to get the token or data file to
the end user securely and to associate it with the user on the server.
Typically, there is a big box of tokens in a secure location, the
security administrator grabs a token, enters the serial number into the
user’s account on the server, and overnights the token to the user. The
next day, he overnights a new PIN number for use with that token.
Obviously, this process is an expensive waste of time for a highly paid
security professional. WiKID Systems’ elegant architecture allows for a
fully automated initial validation when our system is combined with a
trusted network or existing trusted relationship.
First, the end-user installs the client on the device (over-the-air
download or via the Internet installer) and logs into a web site, over
a trusted LAN or using an existing hardware token or some other trusted
mechanism. The web site provides the user with a 12-digit code that
represents the IP address of the authentication server. The user
selects ‘New Domain” to create a new trust relationship and enters the
12-digit number.
The WiKID client generates its own public/private key pair and
sends a request to the server along with it’s public key. The server
responds with a configuration file and its public key, encrypted with
the client’s public key. Already, we have asymmetric encryption! The
user enters his chosen PIN, which is stored on the server and the
server responds with a registration code. The user enters the
registration code into the web site and he is finished. If the
administrator allows automated initial validation, the user can start
generating valid passcodes and can throw away their token (or, more
likely, they can return it for recycling to a non-WiKID user). An
administrator can easily add a user manually as well.
How does WiKID enable Active Directory password resets?
Posted by: root 16 years, 4 months ago
A password-reset domain is configured on the server with Administrator rights to reset users' passwords. When a user forgets their password, they choose the password reset domain on the WiKID client and enter their PIN. If PIN is correct, the encryption valid and the WiKID account is active, the WiKID server resets the Active Directory password to the one-time passcode and forces the user to change their password at the next login.
Will WiKID Strong Authentication work in my network?
Posted by: root 16 years, 4 months ago
The short answer is 'yes'. Chances are that your network devices, whether they are Cisco switches or Nortel VPN concentrators, a custom web-application or a home-baked Linux firewalls, WiKID will work out of the box. Additionally, we can add network protocols with relative ease, if you're not covered by Radius, LDAP or the other major protocols. Finally, we offer a simple API and implementations in a number of languages - Java, COM, Python, PHP and Ruby - so you can easily add two-factor authentication to your custom applications.
Recent Posts
- Blast-RADIUS attack
- The latest WiKID version includes an SBOM
- WiKID 6 is released!
- Log4j CVE-2021-44228
- Questions about 2FA for AD admins
Archive
2024
2022
- December (1)
2021
2019
2018
2017
2016
2015
2014
- December (2)
- November (3)
- October (3)
- September (5)
- August (4)
- July (5)
- June (5)
- May (2)
- April (2)
- March (2)
- February (3)
- January (1)
2013
2012
- December (1)
- November (1)
- October (5)
- September (1)
- August (1)
- June (2)
- May (2)
- April (1)
- March (2)
- February (3)
- January (1)
2011
2010
- December (2)
- November (3)
- October (3)
- September (4)
- August (1)
- July (1)
- June (3)
- May (3)
- April (1)
- March (1)
- February (6)
- January (3)
2009
- December (4)
- November (1)
- October (3)
- September (3)
- August (2)
- July (5)
- June (6)
- May (8)
- April (7)
- March (6)
- February (4)
- January (427)
2008
- December (1)
Categories
- PCI-DSS (2)
- Two-factor authentication (3)
Tags
- wireless-cellular-mobile-devices (7)
- Two-factor authentication (10)
- Wireless, cellular, mobile devices (6)
- NPS (1)
- Phishing and Fraud (111)
- Active Directory (1)
- pam-radius (3)
- privileged access (2)
- Cloud Security (10)
- Mutual Authentication (60)
- Web Application Authentication (1)
- Authentication Attacks (99)
- pci (50)
- Security and Economics (97)
- WiKID (133)
- pam (2)
- VPN (1)
- Installation (2)
- RADIUS Server (1)
- Open Source (64)
- Tutorial (2)
- Strong Authentication (35)
- Information Security (137)
- Transaction Authentication (13)
- Miscellaneous (100)
- Linux (2)
- transaction-authentication (6)
- Two Factor Authentication (254)