@thomasknoll Hi TK. Miss your face

@thomasknoll thank you! As for our current pricing, these are limited-time special rates for early adopters that will surely rise in the future. At this early stage, we feel it's better to focus on feedback and adoption from a greater number of applications rather than focusing on greater revenue from fewer applications.

@shaunsims Hey Shaun, great questions. Regarding your first question, I'll give you the first 10 differences that come to mind: • 2FA solutions like Google Authenticator (GA) and Authy are just single possession authentication factors meant to be used *on top* of passwords while LaunchKey is an entire authentication platform meant to *replace* password systems, and which uses multiple factors of authentication (7 factors in total) • GA and Authy maintain the insecure password layer, while LaunchKey allows the application to remove this layer entirely. This is a superior security approach as it means the application no longer needs to store credentials (a.k.a. hacker bait) • With LaunchKey White Label, you can keep users within your own mobile app, while GA and Authy require the user to leave your mobile app. • With LaunchKey, a device that's lost or stolen can be remotely unpaired and made incompatible with an application whether you have access to the application or not; this isn't possible with GA or Authy • With LaunchKey, the application can actually enforce security policies through the API. For example, an application can restrict authorizations to specific geo-zones, time frames, specific users, or even force the end user to use a certain amount or type of authentication factor. This level of control is impossible with GA, Authy, and others. • With LaunchKey, not only can you log *in* to an application, you can also remotely log *out* of an application. This is impossible with GA and Authy. • GA and Authy utilize an inferior shared secret architecture with an open protocol called time-based one-time passwords (TOTP) while LaunchKey uses public key cryptography with no shared secrets. • If using LaunchKey White Label, you can maximize adoption of your mobile app by requiring it for the most fundamental action of any application (login) • Most devices and smart things are incompatible with GA and Authy because they require the user transpose tokens back into the requesting device, but with no input/output devices (i.e. keyboard), this is impossible. With LaunchKey, all authentication and authorization takes place on the mobile device. • LaunchKey provides more security through an easier user experience.

@shaunsims Regarding your second question: With LaunchKey, instead of users inputting credentials into an application like you're used to with passwords, applications reach out to an individual for authorization by pushing authentication requests to their mobile device. So if we're talking about a website, the user would visit the site, input their username, and the site would push an encrypted login request to their device. The user would receive that request either in the LaunchKey mobile app or through the application's mobile app (if using LaunchKey White Label) where they would authenticate with whatever security factors they've chosen or the application has enforced. The user's response (approved or denied) would be encrypted and sent back to the website, where the application would decrypt the answer and perform the appropriate action (e.g. log the user in). The application can also listen to see if the user logs out from their mobile device as well. This flow works the same regardless of what the application is: a website, a mobile website, a mobile app, a smart lock, or anything else. This is possible because of the fully decentralized nature of LaunchKey meaning 100% of the authentication and authorization resides on the phone. So if an application can send requests to the phone, anything can be authorized in this manner.

@thorpus Thanks Justin, and we totally agree. We believe the world has reached a critical mass of mobile app adoption and it's now time to use these powerful tools in every purse and pocket. With LaunchKey, we're transforming every mobile device into a powerful set of keys, and with LaunchKey White Label, now every mobile app can be a user's own key -- we think that's pretty powerful!

@ahaseeba Hasseb, thank you so much, and super excited to work with an innovative company like BitAccess in the future. If you need any help getting a mobile app off the ground, we can provide you with the framework to do so on any platform: iOS, Android, or Windows Phone.

@jeremywoertink "Want to Sale" ;)

@jeremywoertink Thanks Jeremy, that means a ton coming from a guy like you. Now let's go make your wish come true...

@davewolfson1 Good question, and yes, we do! One of the advantages of LaunchKey's fully decentralized architecture is that it's ideal for smart devices and other online "things" that aren't typically compatible with passwords or tokens because they lack the requisite input/output devices (like a keyboard and monitor) to input that authentication. So whether we're talking about a smart fridge, a server, or some kind of sensor, if it has an internet connection, that thing can push real-time auth requests to anyone using the LaunchKey API. In fact, LaunchKey is even capable of auth'ing to offline devices without internet connections. At the LaunchKey office, we're already auth'ing to offline smart locks, vehicles, and even drones! Instead of using a cloud connection, authentication and authorization takes place locally between a user's device and the offline thing using Bluetooth, NFC, or WiFi. However, this local auth capability is currently only available through custom integrations and not through LaunchKey White Label.

@jpvalery Thanks JP! We do indeed have a free WordPress plugin that utilizes our OAuth provider. We'll also be releasing a direct native WordPress implementation in the future.

@geoffsanders I've seen that :p What do you mean by direct native WordPress implementation in the future ?

@jpvalery So right now, our WP plugin forwards you to our OAuth provider for you to log in there before forwarding you back to your blog. This is a common flow you're probably familiar with things like "Log in with Facebook" and other services that also use OAuth. In the future, you'll be able to use LaunchKey directly within the WP login page, meaning you'll stay on the WP login page and won't be forwarded anywhere.

@jpvalery Agreed! One of the counterintuitive aspects of LaunchKey is that you actually get *more* security through an *easier* (and sexier) user experience.

@lordchris91 Hey Christopher, great question. Check out my answer to Alex Ferber's question for a full explanation :)

@lordchris91 Ohh, fantastic question indeed!!! We actually architected LaunchKey with this in mind... To eliminate the need for companies to have to trust whether or not a user actually authorizes a request or whether we (or an attacker) is simply passing along fake information, LaunchKey utilizes an architecture that makes it both impossible for us to know any information about our users and their responses, as well as making it architecturally impossible for us to forge answers on their behalf. If it's architecturally impossible for us, it's also impossible for a theoretical hacker that's somehow breached our systems. In fact, the LaunchKey service is 100% anonymous. We know nothing about our users: we don't know who they are, we don't know what their responses to requests are, we collect no personally identifying information, and we don't hold any of the data used to authenticate a user -- that's all stored locally on the device, and it's inaccessible to our service as well as the application being secured. We accomplish this through a cryptographic architecture known as a public-key infrastructure whereby all data in between the user's device and the application being secured (i.e. the bank) is 1-way hashed and signed. Only the requesting application with the correct cryptographic key can decipher a user's response, just as only a user's device with the correct key can decipher an application's request. This means that the LaunchKey service acts merely as a conduit for the encrypted data, and nothing more. 2 more points: (1) We continuously and actively audit our technology by 3rd-party independent professional security auditors who analyze our code and platform for security vulnerabilities. We also have an active White Hat Bug Bounty program whereby we will pay any hacker who can identify a vulnerability in our systems. We take security seriously and we believe this means proving it. We have, and we'll continue to do so. (2) And finally, for inherently sensitive organizations like banks that still require a higher degree of trust and control, we offer the ability for LaunchKey to be run on a company's own stack, on-premise, and off of the LaunchKey cloud entirely. With such an approach, the LaunchKey service never touches the authentication process in the first place, and the company retains full and exclusive command and control over the technology and authentication flow.

@atferber Great question! If your device is lost or stolen, you've got a few different options: - You can remotely unpair your device via the LaunchKey website - If you have multiple paired devices, you can unpair your lost device from another device you still retain possession of - You can talk to your application administrator or system administrator and have them sever the link between your lost device and their application Also, keep in mind that as a user, you can setup passive factors of authentication like geofencing to restrict authorization from your device to specific geographic zones, as well as ensure Bluetooth devices that you specify are within proximity before allowing authorization to proceed. This can help you if you leave your device at the airport in another city, for example. The application administrator also has the ability to enforce these same security policies through the API!

@brettdem Good question Brett. While one of the main advantages of LaunchKey is its ability to remove the insecure password layer entirely, there's no reason why LaunchKey can't be utilized alongside a password layer. If an application wants to offer LaunchKey authentication simply as a more secure alternative to only some of its users, this is totally possible. So if compatibility or slow adopters are a concern for an application, we leave it up to the application to decide how they'd like to handle it. In practice, this is no different than traditional 2-step authentication solutions like Google Authenticator.

@geoffsanders So in practice is it a setting a user turns on like 2FA ? Or is it like the option to login with facebook or email? Or a combo of both?

@brettdem We leave it up to the application to pick the integration and/or transition approach that works for them and their users. In practice, it's most like traditional 2FA where the end user would enable the capability in their account center and then pair their device by either scanning a QR code or manually entering a pairing code. From that point forward, they could then authenticate via their device. Now technically, an application could also simply turn passwords off, and send an email to all their users with a QR pairing code and instructions to go download their mobile app to begin using their app for authentication/authorization. In the end, these decisions are left up to the implementer.