1. nVisium Announces Swift.nV

    Herndon, VA--(August 20, 2014) - nVisium, the leading provider of application security tools, services and research for software development, released Swift.nV, a new training tool for identifying and testing vulnerabilities in the Swift programming language today.

    Earlier this summer, Apple released its latest programming language, Swift, for iOS and OS X apps. The language was created to be both simpler and faster for developers to use.

    Seth Law, Director of Research and Development at nVisium, decided to create the intentionally vulnerable Swift.nV iOS application. “Initially, we wanted to know how developers were using the language and what vulnerabilities existed, while exploring existing vulnerabilities and what they look like in Swift,” explained Law.

    Swift.nV is an open source project available to all using Apple’s developer tools. Based off common application security flaws, such as the OWASP Top 10 and OWASP Mobile Top 10 vulnerabilities, this training mechanism was built to teach developers how to prevent and fix security flaws in the Swift programming language. This past June, nVisium released a similar intentionally vulnerable application for Grails called Grails.nV. “Just like Grails.nV, Swift.nV is part of our plan to expand the availability of security training tools for the developer community,” said Jack Mannino, CEO of nVisium.

    According to Law, “It is easier to find vulnerabilities in Swift than in other languages, such as Objective-C, since Swift is easier to learn and develop programs in.” In his opinion, “Swift will probably overtake Objective-C rapidly due to its ease of use.”

    Currently Swift.nV and a list of over a dozen vulnerabilities common in mobile applications are offered on Github, an open-source development community. Seth expects to release tutorial videos and articles in the future on how to find and fix security issues within the Swift programming language. Requests on specific features will be accepted, which are expected to drive future research and development.

    About nVisium

    nVisium was founded in 2009 to build a better way forward for securing software throughout the development life cycle. Headquartered within the Washington DC area, nVisium has proven experience securing what matters most for Fortune 500 clients, innovative software startups, and government organizations. The nVisium team founded and created the OWASP Mobile Security Project, which is a global initiative to improve the state of mobile application security through next-generation secure development techniques. The team has presented research at major industry conferences and continue to develop open source tools for developers and penetration testers. Follow @nVisium.


    Seth Law
  2. Intro to BurpSuite V: Extracting Intrusions

    Hi, Folks,

    Since the last post on Intruder, I've been seeing questions come up on how to pull out data from a large number of results. I wanted to take some time to throw a quick post on how you can leverage some of the more advanced options in Intruder to automatically pull some information out. One of the suggestions that comes straight from PortSwigger is to use the Grep Extract option to pull data from responses.

    Today, I'm going to demonstrate this functionality using WebGOAT.NET, a project that's freely available on OWASP and Github so you can follow along.

    Firstly, we're picking up on the Intro to BurpSuite IV post on Intruder so have a refresher of that here.

    The GOAT

    Now to get started, we're going to use the Forgot Password function over in the Customer section.

    We see that to access this function we simply enter a valid email address into the form field and then it presents us with the Forgot Password question. 

    So let's assume for a moment that we have a large number of target email addresses. This isn't all that outside the realm of possibility with large harvesting sites available like LinkedIn where user email addresses are often shared with the public. If this were a legitimate company pentest, you would easily be able to enumerate through a large number of addresses by guessing or looking up public profiles.

    Let's take a look at Intruder and see how we might be able to automate the enumeration of these questions so we can start guessing the answers.


    We set up Intruder as normal by capturing the request and defining the payload position (as mentioned in the previous Intruder article). In this case, we are attacking the email parameter.

    Now we head over to the Payloads tab and add our simple list of email addresses. In this case, and in the interest of clarity, I've included two (2) known good emails and two (2) known bad emails.

    Next, we're headed over to the Options tab to take advantage of Grep Extract. First, make sure you select the checkbox that says "Extract the following items from responses:".

    Then click the "Add" button.

    Once you click "Add", you're presented with a screen that allows you to use Regex or a simplified version where you specify a beginning string and a delimiter. We know from what we saw in the response that the site says, "Here is the question we have on file for you:" and then provides a question. We can use this tool to pull out information immediately following this statement.

    We use "file for you: " (including the colon) to begin the analysis of the data, and we use the question mark as the ending delimiter because we know that every question the site generates will be presented with that symbol. Once we click "OK", BurpSuite will process this in the results.

    The Attack

    So head up to the main Intruder file menu at the top of BurpSuite and start the attack.

    Now we are presented with a Results window, and look! There are our questions.

    Now you can start guessing the questions and get some passwords.

    But Wait... There's More!

    But wait a second, if we double-click on results, we can examine individual responses. If you look closely, you may notice that the server is setting a cookie for each valid response and is NOT setting a cookie for each invalid response. I wonder if we can use this.

    Let's go ahead and repeat our process by adding this extraction alongside the question. Instead of using the question as the start and the question mark as the delimiter, we're going to use "encr_sec_qu_ans=" as the start and ";" as the delimiter. This should extract the value of this cookie with each response.

    With that added, let's launch the attack again.

    Nice, it looks like we may have gotten the answers, but they look pretty random. Let's put one of these in Decoder to see if it's encoded in some way. Usually in this case I would guess HTML or Base64, but since I don't recognize any HTML encoding, let's go with the latter.

    Decoding our Results

    Using Decoder is as simple as copying a value and selecting an appropriate encoding mechanism from the drop-down; in this case, we chose Base64. Now, decoding it seems to have given us another mangled value so at first glance we may be tempted to throw this away. However, it does seem like valid encoding since we notice that "==" at the end there. Let's try again; maybe they're double encoding the value.

    Nice! It looks like they were. Now, if we had valid email addresses for this site, we could log in as anyone at this point. I hope this helped you understand a little bit more about Intruder. Until next time - send me a question or two about what you'd like to see next in the series. We'll be getting into some more advanced topics soon.

    For more information on using Burp's Grep Extract functionality, check out John Poulin's great post on using Recursive Grep to Test CSRF Protected Applications.

    Ken is a Senior Security Consultant at nVisium. He works hard to defend our clients' web applications and provide real solutions to their security concerns. Ken loves his technology and can always be found researching new languages, gadgets, applications, and hardware. Ken began his career in software product management, but quickly realized he'd rather be down in the weeds. Armed with the project management mindset, he dove head first into networking and development, and came out with a passion for security.

    Ken is creative at heart and has an innate desire to provide an environment where clients are excited to learn about and implement good, proactive, and efficient security practices that compliment an organization rather than hold it back. Ken has worked in the IT industry for 7 years for companies such as HyperOffice, LivingSocial, Citrix and even the US ARMY which has enabled him to gain experience in all walks of business from a humble startup to a fully fledged enterprise, and he loves every waking second of what he does.
  3. iOS Assessments with Burp + iFunBox + SQLite

    In January, I wrote a post on performing Android Assessments with GenyMotion + Burp so I thought it was about time I wrote a similar post on performing iOS assessments.

    Aside from a company by the name of Virtual that has a private beta on a virtualization platform for iOS, there are no other virtualization options.

    The three options for performing an iOS assessment at the moment are to use the iOS simulator that comes with XCode (only works with Macs, requires the application's code), a jailbroken/developer licensed iOS device, or a non-jailbroken iOS device with iFunBox (which I will go over in this post).

    For this blog post I will be using the following tools:
    - Locked iPhone 4s running iOS 7.1.2
    - Burp Free 1.6
    - Burp Pro 1.6.03
    - SQLite Database Browser 3.2.0
    - iFunBox 1.5 for Mac

    The sections in this post will be as follows:
    - Configuring Burp and an iOS Hardware Device to Pass Traffic Through Burp
    - Installing the Burp Cert on an iOS Device in Order to View Encrypted Traffic
    - Using iFunBox to View iOS Device File System
    - Using SQLite Database Browser to View Information Stored in Application Database

    Configuring Burp and an iOS Hardware Device to Pass Traffic Through Burp

    For performing security assessments against applications in development as well as in production, it is necessary to view the web traffic that is passed back and forth between the client (the iOS application installed on an end device) and its corresponding server. It is possible to configure an iOS device to pass all of its web traffic through a web proxy such as Burp. Verify the current IP address of the testing machine.

    In the instance above, the IP address of the testing machine is Set the proxy settings within iOS to pass all web traffic to the testing machine. Within your iOS device, go to Settings -> Wi-Fi. Click on your current Wi-Fi network. There should be configuration settings to set the HTTP Proxy if you scroll to the bottom of the page that displays all of the current Wi-Fi information. Switch the HTTP Proxy setting to 'Manual' and use the IP address of the testing machine as the 'Server' (in our case, and set the port to 8080.

    Launch Burp Suite Pro or Free. Click on the top Proxy tab then click on the Options secondary tab. Lastly, click on the "Add" button to add a new proxy listener.

    Specify the listener port that was defined within the iOS device (in my case, port 8080). Also, click on the "Specific address" radio button and from the drop down select the IP address specified within the iOS device (in my case it was When complete click 'OK' to return to the previous screen.

    Verify that the new proxy listener has been added and that a check box is located next to the listener to ensure it is enabled.

    If all of the settings were configured properly, Burp should now see web traffic passed to it by the iOS device.

    Installing the Burp Cert on an iOS Device in Order to View Encrypted Traffic

    At this point, all web traffic should be passing from the iOS device to Burp. However, if any applications are communicating over HTTPS, the iOS device will throw errors. This happens because the Burp Certificate Authority (CA) Certificate is not yet trusted by the iOS device. Starting with Burp 1.6, the method of retrieving the Burp certificate is the same regardless of whether you are using Burp Free or Burp Pro.

    Click on the Proxy tab and the Options secondary tab. Click on the "CA certificate..." button.

    Export as "Certificate in DER format". Click "Next". Name the Certificate <name>.cer. Save it in an easily accessible location.

    The easiest way to get the certificate onto your iOS device is to email the Burp certificate to yourself on your iOS device. iOS will prompt you for installing the certificate once you open the certificate attachment within your email. Click "Install".

    On the next screen click "Install" again.

    Lastly, iOS will require you to enter your passcode or to set a passcode if you have not already done so.

    Once the certificate is successfully installed, iOS should return you to a screen that has a green "Trusted" check for the PortSwigger certificate. You should now be able to capture encrypted traffic between your iOS device/application and its corresponding server.

    Using iFunBox to View iOS Device File System

    For the purposes of demonstrating iFunBox's capabilities, I will be using the ESPN Score Center application downloaded from the iTunes Store.

    Use an iOS hardware data cable to connect your iOS device to your testing machine and launch iFunBox. iFunBox should detect the iOS device and display a few options under the device.

    Expanding the tree under "User Applications" displays all of the installed applications on the device.

    Double-click on the "SportsCenter" application, revealing the file system behind the application.

    This application allows you to drill down into the file system of the application (not the operating system) and view all of the files, logs, and databases that could potentially store sensitive information without having to jailbreak your iOS device.

    Using SQLite Database Browser to View Information Stored in Application Database

    You can download SQLite Database Browser from here.

    In tandem with iFunBox, SQLite Database Browser can be used to view databases located within application file systems in order to determine the types of information that are being stored by the application.

    In the example below, there are two databases located within the application.

    These databases can be opened one at a time within iFunBox (the database will open in SQLite Database Viewer if you have it installed) or downloaded to your testing machine.

    Downloading the "ApplicationCache.db" database and opening it within SQLite Database Viewer gives you a view of the database structure as well as the data that resides within.

    I hope this information is useful and eases some of the pain of iOS application assessments. I'd love to hear your thoughts.

    Abdullah Munawar is an application security consultant at nVisium who specializes in mobile application testing and ripping apart new things. He previously worked on the security teams for various federal agencies including aviation organizations and the financial industry, with over 7 years of experience. Abdullah attempts humor on a daily basis and succeeds most of the time, every time.
  4. Swift Core Data Format String Injection

    ...Or how I developed a love/hate relationship with format strings

    The last couple of months since WWDC have been an interesting exercise in forgetting the complexity of Objective-C (ObjC), falling in love with Swift, and then realizing Apple hasn't completely dropped ObjC for Swift. Programming an iOS application in Swift quickly becomes a translation effort in converting ObjC code to use Swift syntax and format, since even Apple's own developer site still references ObjC examples in documentation and Class References. In addition, the Xcode 6 beta and Swift are not a complete match. Auto-generated code often fails when using Apple's provided templates, including Cocoa Touch Classes. Pay attention to the compiler errors and warnings before trying to actually deploy anything.

    This post explores Swift's interaction with Core Data and how to break (and secure) format strings using wildcards and injection techniques. Core Data's is Apple's object graph and persistence framework that makes it easy for Mac and iOS developers to store and retrieve data without the overhead of dealing with databases or other network services. If you are unfamiliar with Core Data, Apple's tutorial is quite extensive and can take some time to get through. I would recommend Techtopia's iOS 7 Core Data tutorial to get the basic gist of working with the technology. The one issue is that most tutorials still only address Core Data use with ObjC, so translation to Swift is something you'll have to figure out.

    Interaction with Core Data hasn't changed much between ObjC and Swift. The following Swift code snippet shows how a test application logs into an iOS application based on the 'User' object that is stored in as a Core Data object.

    The function is fairly straightforward, but the interesting part to a security professional is the NSPredicate declaration, which is defined as a format string that limits what data is returned from Core Data.

    This format string should set off all sorts of alarm bells to anyone creating authentication routines. This application does not follow proper security best practices when creating the predicate or building the associated format string.

    First of all, the use of the 'LIKE' statement enables simple bypass of authentication within this app. A failed attempt at logging into the app results in:

    But the use of wildcards (this is the star '*' for format strings)

    results in successful entry into the app.

    As in creation of secure SQL statements, use of the 'LIKE' keyword within NSPredicate creation should be avoided for everything but search utilities. Not only does it allow an attacker to present wildcards to Core Data, it also allows an attacker to enumerate through all of the relevant accounts in the database (a*, b*, etc). In fact, any keyword that allows the use of wildcards (e.g. LIKE, CONTAINS) or uses them implicitly (BEGINSWITH, ENDSWITH) should be avoided. A full description of format string syntax can be found in Apple's Predicate Programming Guide.

    Remediation of wildcard injection vulnerabilities is a fairly simple matter. First of all, convert the format string 'LIKE' keyword to '='. A 'LIKE' query is unnecessary within the authentication routine.

    This simple change corrects the easy authentication bypass seen in the previous example.

    However, the format string is still vulnerable to injection and can be bypassed by using more complicated predicate instructions. For example, entering the string ') OR 1=1 OR (password LIKE '* into the username field allows an attacker to successfully bypass the authentication requirement.

    This attack is very similar to SQL Injection and is the result of string concatenation during format string creation. To complete the secure format string, move the user input to format string objects that are added at runtime as follows.

    This fully escapes any attempts at injection using double quotes, which are required to escape out of the format string when built in this manner.

    Finally, our application login function is secure from format string injection.

    As an application penetration tester, identifying format string injection points is critical to determining the security of an application. During an assessment, identification of Core Data use can be difficult. Some fields may be linked to user preferences or backend web services. The only sure way to identify these vulnerabilities is through source code analysis. Given client limitations in providing an Xcode project for analysis, fuzz each available field with the values identified in this guide, including the single quote ('), double quote ("), and wildcard character (*).

    In future blog posts, we will explore other mobile security issues as they relate to Swift and iOS development, including the OWASP Mobile Top 10. In the meantime, feel free to reach out to me (seth [at] or @sethlaw) with issues or questions related to Swift Security.

    Happy Hacking.


    Seth Law is the Director of Research & Development of nVisium and wrangles the internal and external research efforts to improve understanding of application security. He spends the majority of his time thinking up new ways to secure web and mobile applications, but has been known to code when the need arises.

    For the past 12 years, Seth has worked within multiple disciplines in the security field, from software development to network protection, both as a manager and individual contributor. During the last few years, Seth has honed his application security skills using offensive and defensive techniques, including tool development.

    Seth is currently involved in multiple open source projects and is working with others to advance the state of mobile security testing tools. He has spoken previously at Blackhat, Defcon, and other security conferences.

    Seth has worked across multiple sectors in the last 14 years for companies including Iomega, Early Warning Services, Fishnet Security, and Zions Bancorporation.
  5. Intro to BurpSuite Part IV: Being Intrusive

    Welcome to our 4th installment of Intro to BurpSuite. This time around we're going to focus on using another tool in the BurpSuite arsenal to send targeted requests to a web server, rapid-fire. Intruder can be used for a variety of fuzzing and bruteforce techniques using premade lists or automatically generated input. This is amazingly useful for those list-based tasks as well, such as mapping a site or discovering hidden directories and errors.


    Before I get started, I should mention that I'm using the same environment settings I created in the first part of the Burp series. I recommend reviewing this post if you're new to Burp and are just getting started.

    Secondly, we're going to be using some pre-made lists and Burp-generated lists with Intruder, so if you want to follow along exactly, please download the wordlists from SVNDigger. They're a great starting point and can really help with that first step.

    With that all out of the way, we can get into the meat of it with Intruder.

    As I mentioned, we're going to use Intruder to send a massive number of requests, so be aware that unless you lower the request options (which we'll touch on), this can be a noisy attack. Staying under the radar can be a concern for some red team exercises, but for the purposes of this article, we're going to be loud and obnoxious.

    We're going to use a basic exercise on to demonstrate Intruder's capabilities, but we're only going to cover one of the primary functions: Simple list. Simple list allows you to attack with a pre-made list (the one from SVN digger that I mentioned, in this case) and Brute Forcer allows you to specify a character set which Burp will then use to generate a list on the fly. This is useful for random values such as passwords with a known character length.

    In the first example, we're going to look at basic exercise number 3 which is located here:

    Keep in mind, there's an easier way to beat this "challenge" but we're using this site for demonstration purposes, and we'll leave it to you to use this technique creatively to perhaps tackle some of the more advanced portions of the site as a learning tool.

    So we can see that we have a password field and not much else. We also can see that the description mentions a password file. Without much knowledge of the site (spoiler alert), we may be inclined to view the source and find some interesting tidbits of information, but in this case, previous experience with would point us to start sniffing out php pages. And that's exactly what we're going to do.

    The Setup

    If we send the request to Intruder...

    we can see over 443 on the Target tab. If we take a look at the Positions tab, we see some interesting portions of the request highlighted in orange. These are assumptions BurpSuite makes for possible entry points. These are merely suggestions, but we just want to do some discovery, so let's take a look at manipulating some of the information in the request.

    First, clear the current field sections using the button to the right.

    Then put your cursor after "GET /missions/basic/3/" and click "Add §" twice.

    You'll see two section signs (§) highlighted in orange, and you'll want to append ".php". Since we're doing discovery and we have an idea that this is a php based site, we're appending a file extension since it's the most likely to occur.

    It should look like this:

    Now, a little explanation of what's going on here. We've cleared all automatically created sections and added our own. This section sign pair (§§) indicates that we're going to insert our payload between these two points. So if our payload was the word "admin" it would send the request with:

    GET /missions/basic/3/admin.php

    Burp will send every word in our payload through that entry point. This means that Burp will be sending a large number of pre-determined requests to the server without having to manually enter each one into Repeater or through the proxy. We can then view the results in a consolidated view.

    Next, let's take a look at the Payloads tab.

    Defining our Payload

    First, we want to define our payload set. For this demonstration, we're going to choose Simple list and load the list from SVN Digger.

    Then we're going to load the list under Payload Options. Click the "Load..." button and pick the all-extensionless.txt file. We are choosing this file because we defined our extension in the positions tab as ".php"

    If done correctly, you should see a list like this pop up in the Payload Options section.

    There are some other options, but nothing we have to worry about at this point.

    Launching the Attack (or the Discovery in this case)

    Let's go ahead and run the attack. Beginning Intruder can be a bit unintuitive at first. Select "Intruder" from the top of the window in the menu, and click "Start attack".

    This will begin the attack, and you'll be greeted with a results window. Click the Status column to sort by the response code.

    It shouldn't take too long to see that "password" returns a 200 response. If you take a look at the response in the web browser, you'll see the password of the password file. Entering that into the password field will pass the challenge.

    About that Throttle

    I mentioned at the beginning of the post that this was going to be noisy, and I meant it. If you launched this sort of discovery on a pen-test, you would probably raise some alarms. Since we're hitting a site that is meant to be attacked, we don't have to worry about it so much. If you're authorized to go full throttle on a site, this would also be fine, but if you're trying to remain stealthy, it may be a good idea to take a look at the throttling options offered in the Options tab.

    This Request Engine section gives you control over throttling, threads, and retry options, and even allows you to delay the start of the attack. This is useful if you want to send requests with a delay in order to limit the chances of defense discovering your attack.

    Some Afterthoughts...

    Now, I want to end this post with the idea that this is simply a demonstration of BurpSuite's Intruder to introduce newcomers to the interface. If you ran the page through the proxy, you may have noticed that the password.php file was referenced in the parameters and we could have achieved the same results without Intruder, but the beauty of offensive techniques is that you can arrive at a positive result in a variety of ways, some more complicated than others. 

    Intruder also has many other payload options, including BruteForcer, which allows you to specify a character set and length to your payloads. This is especially useful when attacking passwords where you know the complexity requirements, and it's especially effective against sites with weak complexity requirements.

    There are a few other, more advanced techniques that allow you to use Intruder with a great deal of imagination and creativity to get some interesting results. The tool is built to be versatile and it certainly succeeds in that respect. I don't want to go down the rabbit hole, but I will be posting more information on some of the more advanced Intruder functions later in the series as we wrap up the modules. For now, we're just getting warmed up, and I encourage you to stay tuned for more.

    Ken is a Senior Security Consultant at nVisium. He works hard to defend our clients' web applications and provide real solutions to their security concerns. Ken loves his technology and can always be found researching new languages, gadgets, applications, and hardware. Ken began his career in software product management, but quickly realized he'd rather be down in the weeds. Armed with the project management mindset, he dove head first into networking and development, and came out with a passion for security.

    Ken is creative at heart and has an innate desire to provide an environment where clients are excited to learn about and implement good, proactive, and efficient security practices that compliment an organization rather than hold it back. Ken has worked in the IT industry for 7 years for companies such as HyperOffice, LivingSocial, Citrix and even the US ARMY which has enabled him to gain experience in all walks of business from a humble startup to a fully fledged enterprise, and he loves every waking second of what he does.
  6. The Role of a Designer in an Application Security Company

    Having recently started at nVisium as a designer, my role in an application security oriented company is clearly unlike most others on the team. I joined the company as part of the effort to expand the new development team while the majority of my colleagues are in the consultation service that the company has its roots in.

    As for myself, I am a graphic designer by trade, with some side knowledge of front-end web development and user research, yet my job so far consists of 70% front-end development, 20% user research, and 10% graphic design, which means most of the time I am given the challenges outside of my realm of familiarity. But that was not my foremost concern.

    Here are some of the things I have noticed in the past four weeks:


    Whenever you become part of a new environment, there will be the initial learning curve of trying to understand how to work with everyone, as people have different working styles. However, joining the team bearing a new role steepens that curve quite a bit. On top of adjusting to the personalities and work habits, it was quite evident that the question “Can I ask Hong to do this?” was always being asked because the team did not have a dedicated in-house designer prior to my arrival.


    I used to work with designer peers, so it was not until I joined nVisium that I realized the amazement people can have toward my work. For example, I recently produced this logo animation in a two hour time frame:

    ...and it led to our CTO, Ken Johnson, jokingly telling me, “From now on I am just going to shut up and let you do whatever you need to do.” While it is indeed pleasant to receive positive encouragement, this is problematic as well because (1) I am aware that I am not a magician and my knowledge only covers a few fields of design, and (2) my colleagues trust that I always have the ultimate say with anything design-related, leading to hiccups in feedback, which I will explain in the next point.


    The importance of feedback cannot be overstated to design professionals. Unlike code, a design can only be evaluated by observing other people responding and/or using it. In an environment where there is more than one designer, members within the team can critically assess and critique each other’s work as it develops over time, thus producing products with finer quality before they go out to the customers. It is trickier in my current situation as I am the sole person in such role. Once in a while, I will find myself stuck with nuisances that would otherwise be easy to resolve if there was another pair of trained eyes. However, there are times that I do receive suggestions that are valid and yet not applicable because of the constraints of time, resources, or experience. In this case, offering an appropriate rejection is a delicate matter: You certainly do not want to give the false impression that only you are entitled to say “yay” or “nay” in a design process because that will stall the feedback loop and sour your relationship with your colleagues.

    Prioritization of Tasks

    I thought I had a lot of tasks while I was in college, but working for a startup has taken the challenge of managing my tasks to another level. At any given moment, there are at least 10 things that need to be done, and most of them can be broken down into smaller parts, doubling or tripling the actual number. It can be as small as increasing the leading of a text paragraph on the home site, or as time-consuming as putting together a graphic style guide (which can be broken down into at least 6-8 parts) to be used until a rebrand is introduced to the company. The battle between time and ROI is constant as I move from one thing to another. To use an example, I use a mind map to manage my to-do list and my tasks translates to something that looks like:

    Importance of Security

    This is the most fascinating part of all because it defies all of my previous knowledge—We are a security company so oftentimes the importance of security is more emphasized than other factors, even if it might sacrifice UX slightly. To give an example: Just last week, I was discussing with Ken about the inclusion of reCAPTCHA to our home site contact form and whether or not it turns away users who find it challenging to use. This is not to say we do not value UX in our development; we are simply well aware of how insecure features can cause harm to both ourselves and our users in the long run. In a non-security based team, usually it is the, if not the most, overlooked part of the operation. In fact, I have been in situations where million dollar proposal documents are transferred many times through insecure networks that can be easily intercepted, but I wouldn’t have known this until I started learning secure practices from my current colleagues.

    My observations thus far have led to a single question: What are the most crucial responsibilities I have as the first designer of the team? Considering that I just joined not too long ago, I do not have a comprehensive answer yet. It is safe to say that there will be a follow-up post on this topic a few weeks down the road. Until then, let’s see if I can trim down my mind map faster than it further branches out.

    Hong is nVisium’s lead designer. He is responsible for everything from producing infographics to accompany the team’s research to designing the landing page—We keep him very busy. Coming from a graphic design background, Hong is fascinated by the complexity of human behavior and he is particularly interested in UX design. He is also a semi-polyglot (Klingon not included) whose brain occasionally fails to function properly because it is processing five different languages.

    When he is not occupied, he enjoys reading Japanese comics, playing turn-based strategy games... and reading more psychology related books.