Yes - apps are eligible. You will want to talk to us to get help with this; your app will need to talk to our app for it to work - we can show you how.
Sure - can you let me know what platform(s) you're developing for, and if you know already - what technology/languages/toolchain you're looking to develop with? In particular, have you planned your UI tech for the authentication part of your app (username/password/social-auth/etc bits) - like - will you be using browser technology (e.g. embedded webkit with html forms) or native controls?
1. Provides fast, strong, but easy 2FA with mutual-authentication: to protect logins against phishing, and to protect end-users against their own mistakes, like bad passwords, using the same passwords in many places, etc.
2. Provides digital signatures for transaction-verification or any other kind of rich out-of-band 2-way messaging you might need: this protects everyone against malware, and protects you against nasty users attempting to defraud you (due to our non-repudiation)
3. Provides all the supporting infrastructure to make #1 and #2 possible, *including* the enrollment system and the secure end-user management system: this makes life very easy for you, and importantly, protects everyone against social engineering and authentication-bypass problems, plus this reduces customer-support needs, because users do everything safely themselves.
Number 3, and number 1, are implemented using an HTML container control - this means that your app can automatically contact and communicate with our app all in the one device, without you needing to do anything special. This is important to make everything easy for your users: they can "enrol" with just a couple of taps, and they can get safe-and-strong 2FA authentication with just one single tap. You can also use exactly the same code on any platform (android, ios, windowsphone, and even blackberry) - it all "just works".
Number 2, if you need this, is just API calls - no controls needed.
Can you let me know (either here or by email) what kind of app you're writing? If I know a bit more about what you're planning to do, I can recommend the best solution for you in more detail.
6 comments
Chris Drake Manager • almost 10 years ago
Yes - apps are eligible. You will want to talk to us to get help with this; your app will need to talk to our app for it to work - we can show you how.
Royce Raju Beena • almost 10 years ago
Yeah , I went through the website and I didn't find any SDKs . Please share more info about the same .Thanks
Chris Drake Manager • almost 10 years ago
Sure - can you let me know what platform(s) you're developing for, and if you know already - what technology/languages/toolchain you're looking to develop with? In particular, have you planned your UI tech for the authentication part of your app (username/password/social-auth/etc bits) - like - will you be using browser technology (e.g. embedded webkit with html forms) or native controls?
Royce Raju Beena • almost 10 years ago
I'm developing for Android. Yes, I've planned my authentication part with social-auth and will be using native controls.
Royce Raju Beena • almost 10 years ago
Any updates on this ?
Chris Drake Manager • almost 10 years ago
Hi Royce.
I will quickly summarise what CryptoPhoto does:
1. Provides fast, strong, but easy 2FA with mutual-authentication: to protect logins against phishing, and to protect end-users against their own mistakes, like bad passwords, using the same passwords in many places, etc.
2. Provides digital signatures for transaction-verification or any other kind of rich out-of-band 2-way messaging you might need: this protects everyone against malware, and protects you against nasty users attempting to defraud you (due to our non-repudiation)
3. Provides all the supporting infrastructure to make #1 and #2 possible, *including* the enrollment system and the secure end-user management system: this makes life very easy for you, and importantly, protects everyone against social engineering and authentication-bypass problems, plus this reduces customer-support needs, because users do everything safely themselves.
Number 3, and number 1, are implemented using an HTML container control - this means that your app can automatically contact and communicate with our app all in the one device, without you needing to do anything special. This is important to make everything easy for your users: they can "enrol" with just a couple of taps, and they can get safe-and-strong 2FA authentication with just one single tap. You can also use exactly the same code on any platform (android, ios, windowsphone, and even blackberry) - it all "just works".
Number 2, if you need this, is just API calls - no controls needed.
Can you let me know (either here or by email) what kind of app you're writing? If I know a bit more about what you're planning to do, I can recommend the best solution for you in more detail.