Posted by:
admin
11 years, 6 months ago
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.
Today it is important to be able to automate all the things, so you can also automate this process via our API. There are three functions related to pre-registration, the first allows you to combine our typical registration process with a pre-registration code. Here it is, once again taken from our API demonstration page /opt/WiKID/tomcat/WiKIDAdmin/example.jsp:
<% if (request.getParameter("action") != null && request.getParameter("action").equalsIgnoreCase("Pre-register")) { res = wc.preRegister(request.getParameter("preregcode"), request.getParameter("tokenregcode"), request.getParameter("servercode")); if (res == 0) { status = "Success"; } else { status = "Failed (" + res + ")"; } } %>
The XML looks like:
<transaction>
<type>10</type>
<data>
<token-registration-code>5D4p9Xy3</token-registration-code>
<pre-registration-code>1234567890123456789012345</pre-registration-code>
<domaincode>127000000001</domaincode>
<error-code>null</error-code>
<result>null</result>
</data>
</transaction>
Even after you securely deliver your pre-registration codes to your users, some might have lost theirs. They might need to call the help desk to get a new one. This function will add a new pre-registration code to your WiKID Strong Authentication server, optionally over-writing an existing code:
<% if (request.getParameter("action") != null && request.getParameter("action").equalsIgnoreCase("Add Pre-Registration Code")) { PreRegistration preRegistration = new PreRegistration(request.getParameter("user"), request.getParameter("preregcode"), request.getParameter("servercode")); boolean override = request.getParameter("override")!=null; PreRegistration pr = wc.addPreRegistration(preRegistration, override); if (pr.isSuccessful()) { status = "Success"; } else { status = "Failed (" + pr.getMessage() + ")"; } } %>
You might want to create a number of new pre-registration codes when rolling out two-factor authentication:
<% if (request.getParameter("action") != null && request.getParameter("action").equalsIgnoreCase("Add All Pre-Registration Codes")) { List preRegistrationList = new ArrayList(); for(int i = 0; i<3; i++){ if(request.getParameter("user"+i).trim().length()>0 && request.getParameter("preregcode"+i).trim().length()>0 && request.getParameter("servercode"+i).trim().length()>0){ PreRegistration preRegistration = new PreRegistration(request.getParameter("user"+i), request.getParameter("preregcode"+i), request.getParameter("servercode"+i)); preRegistrationList.add(preRegistration); } } boolean override = request.getParameter("override")!=null; List prs = wc.addPreRegistrations(preRegistrationList,override); StringBuffer sb = new StringBuffer(); for(PreRegistration pr : prs){ if (pr.isSuccessful()) { sb.append(pr.getUserID()+":Success, "); } else { sb.append(pr.getUserID()+":Failed (" + pr.getMessage() + "), "); } } status = sb.toString(); } %>
One of the key expenses and logistical hassles we attacked with WiKID. Allowing users to self-register their tokens based on existing trusted credentials greatly reduces the cost of two-factor authentication. Just as importantly, it allows the security administrators to manage the process rather than mail out hardware tokens and perform other logistics. As with much of our API, we added the ability to pre-register users based on customer requests. We greatly appreciate any feedback that we can incorporate to improve the WiKID Strong Authenitcation System.
Up next in this series of posts is user management and reporting.
Share on Twitter Share on FacebookRecent 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)