Skip to main content

The WiKID Blog

Viewing posts from May, 2013

Google search reveals private Telstra customer data

A man googling for some information on SMS carrier access codes stumbled upon private Telstra customer data. The data could be used to authenticate a user to the phone company, allowing account take-over.  There appears to be a pattern:

More on user validation for two-factor authentication via our API

In the previous post in this series on using the wAuth API, we discussed how you can create a simple application that allows customer service reps or even 3rd parties in a multi-tenant environment validate users for two-factor authentication. As with all things tech, there is more than one way to skin that cat. The PC tokens support pre-registration. With pre-registration, a list of usernames and pre-registration codes is uploaded to the server. The pre-registration codes are then delivered to the users in some secure manner. The users enter the WiKID Domain identifier, their PIN and the pre-registration code into the software token and they are automatically registered. You generate this list of pre-registration codes - we do not have a copy of them at all. Under the Users tab of the WiKIDAdmin webui there is an option to import a text file of users.

Wisdom about two-factor authentication based on facts

There is one quote in the Verizon DBIR that speaks volumes about the value of two-factor authentication to enterprise users:

PCI Compliance

If you are using the WiKID Strong Authentication System to meet the PCI-DSS requirement for two-factor authentication, you should upgrade to the latest version of the server.  We have a couple of fixes that popped in a scan.  See the Changelogs.  In particular, build 3.5.0-b1411 disabled unnecessary HTTP methods and 3.5.0-b1403 removed weak SSL ciphers from the WiKIDAdmin.

Using the WiKID API in your two-factor authentication roll-out

Time to get down to business with the wAuth API. The API exposes all the key functionality of the WiKID server allowing you to automate many typical two-factor authentication tasks and push functionality to the appropriate parties, such as the corporate helpdesk or HR. In this series of blog posts, I'll show you how to create the communication channel, register users and authenticate an one-time passcode. For our example, we will be setting up a CSR application in Java on a box with the IP address of 192.168.1.10. The WiKID server has an internal IP of 192.168.1.20 and an external IP of 174.129.6.100. So, the zero-padded domain identifier for the WiKID server is 174129006100. For demonstration purposes, our CSR application will be a tomcat JSP on linux in a directory called /opt/tomcat/webapps/CSR. I assume that this application will be protected by existing credentials appropriate for this level of securing and granting access.

Recent Posts

Archive

2017
2016
2015
2014
2013
2012
2011
2010
2009
2008

Categories

Tags

Authors

Feeds

RSS / Atom