According to Yubico, the Yubikey 5 supports many different "applications": OTP, OATH, PIV, and FIDO/U2F to name the main ones.
My question is... how do I know which one my Yubikey is using for a given website?
For example, say I register my key to protect my Google account. When I log into Google and it tells me to press the button... is it using OTP? FIDO/U2F? OATH? Magic?
I can't seem to find any information on this, but it seems like an important question because by default it seems like pressing the button is sending keyboard strokes to the computer in the form of a OTP that needs to be authenticated against YubiCloud which I don't necessarily want.
In general, when you are asked to tap your YubiKey in a text field, which then emits a 44-character string "cccc....", you are using OTP.
If a modal dialog pops up asking you for a security key (or a passkey), you are using FIDO.
Other YubiKey applications are not often seen on web sites. Google in particular uses FIDO these days.
Related
I'm building a Raspberry Pi based valve-amplified MP3 player, housed in a restored Westminster radio case:
http://www.youtube.com/watch?v=oTabLcVgvwo
I'd like to write a simple Free client that starts playing a particular named playlist ('Westiamp', which is the name of the project) immediately. It'll also interface to a USB-connected control panel for skipping between tracks, etc.
There will be a simple web UI for entering username and password to log in to Spotify, and WiFi details.
My question relates to the API Key. There are several options I can see here:
apply for a personal API key, and release it along with the source code
apply for an API key for the project, and release it along with the source code
provide an option in the web UI for the user to specify an API key, and use that
I would much rather not distribute a personal API key, and I don't think usability would be helped by requiring any user of the software to apply for their own key.
Is there a Spotify-approved process here? I've tried posting on the community forum (silence) and asking support (who directed me here).
It's strictly against the Spotify Terms of Service to distribute your key with source code.
If you're only distributing binaries with the C API key compiled in, that's fine. Otherwise, you must require the end user of your code to supply the C key at compile-time, or ask for the binary key at runtime.
When I am sending sms via j2me application, before message sent it appears question for can I use internet to sent message. Is it possible to exit this question to not appear?
This is happening because you Accessing HTTP & SMS API. For using such API you need to signed your Java ME Application. For Signed a the Java ME Application, you need to purchase Signing Certificate from VeriSign or Thawte Site by paying the Fees.
Plesae visit this link
For VeriSign's certificate, they costs 20K per certificate.
I think you can skip the prompt but your application must be signed. However, even if your application is signed, on some devices, the prompt will still appear once. This usually (or always) occurs on the session's first use of the Wireless Messaging API. This happens because the access to this API is set to something like "Ask first time."
If your app is signed, you can manually set the access to the wireless network settings to (something like) "Always allow." If it is set to (something like) this, the prompt will not appear.
For apps that are not signed, the option "Always allow" is not available. However, on most devices, the next best option is available: "Ask first time."
Well, the bad thing is, you are going to set it manually. The good thing, however, is that you are not going spend so much money just to set it to "Ask first time." :D
J2ME by the platform design have the drawbacks in which users of the applications are asked to select yes or no for any attempt to use any of the secure API's. Some devices gives this alerts in such a way which will make the end user to think if he should go ahead or stop it there. By digitally signing the application, one can reduce the alerts to levels depending on the device KVM implementation and the number of secure APIs in use.
In some device having Symbian OS Feature Pack 1, the prompts continue even if the code is signed.
This behavior of J2ME makes the applications less developer friendly and less user friendly. I think this is a wrong strategy and model adopted by SUN. There is some thing called Verified by Java in which you can get your application signed using a certificate which will make the application work seamlessly and without prompts in the end user device but unfortunately the process of getting that certification is expensive and not practical. The only advantage of J2ME platform is that it allows less chances of virus or malware code to be executed on the end user device. I think the trade off between security and ease of user use is not worked well and that is the reason we don't see very good apps in J2ME.
In contrast, Android for example, lets the user see all the permissions prior to installation of the app and the user is not bothered at run time when those secure API are used. That is the reason we see millions of apps there and not in J2ME. We can always say this approach had led to many malware types of applications in the end android user device but that is how it goes, people need to have smooth apps running and are happy with them.
What are your thoughts about this issue in regards to an e-commerce environment?
Do you think it is wise to turn autocomplete off on all sensitive input fields such as passwords (for log-in areas), or will this just inconvenience the client?
I hate websites that do that. It is the client's decision if they want to save passwords or not. What is particularly irksome is that this attribute breaks OS X's native KeyChain support. So, even though the user has stored his password in a secure file, and authorized themselves and the application to use it, the website still thinks it knows better. Just plain annoying.
An eCommerce application I worked on several years ago underwent a security audit and one of their recommendations was to disable autocomplete for sensitive fields.
It wasn't a strict requirement, but it probably will be at some point, given how eCommerce standards are these days..
Unless it is a highly-secure site, I would tend to leave autocomplete on. If it is for a password field, the browser will prompt the user if they want to save the information, at which point the user can make their own decision.
I really dislike that when I start to type in my credit card number and it lists all of the numbers I have used in the past, as well as the 3 digit code. Not cool IMO.
It depends what you mean by e-commerce. In Internet banking you should disable autocomplete. In online shopping - not necessarily.
It's worth remembering that autocomplete does not force remembering passwords. User has to agree to store their credentials, so they always can reject.
I concur. By habit, I leave autocomplete on. However, there was a project for the air force I was working on that had a requirement to disble autocomplete. Really depends on your requirements.
I actually don't think i've ever seen "autocomplete" work on a password field.
Autocomplete(when you start typing something in a form field, and the browser popups up a list of suggestions), and asking the browser to remember your user name and password are two different things.
If you're talking about the browser feature that remembers your username and password, i'm not aware of a way for you to disable that on the user's machine.
I use password/form managers like 1Password and RoboForm specifically to get around websites that disable autocomplete; these add-ons typically ignore the website's preferences in favor of their own more sophisticated logic.
Most e-commerce sites disable autocomplete for credit card fields. They store and redisplay the info when an authenticated user returns, then only require the user to re-enter the CVV. This way the site gets users to sign up (otherwise, they'd have to re-enter the full CC info every time), keeps the CC info masked on subsequent visits, and only burdens the user with entering a three-digit number. (It's also a small way of building secure practice around CC numbers so users will hopefully be more protective of them.)
Keep in mind that setting autocomplete on/off only addresses confidentiality of data for shared environments, i.e. more than one person accesses the same browser. For example, if your app were intended for a classroom, then it would make more sense to disable autocomplete entirely since the app will be re-used in the same browser by many different people.
Consider it an (in)convenience feature, not a security feature. You can't protect users from every dumb mistake when sharing browsers (like not logging out) and, to be nicer to dumb users, it won't have any bearing on client-side attacks like keyloggers. If the shared environment isn't secure, then your app can't do much to protect its users.
The talk of internet town today is the SNAFU that led to dozens of Facebook users being led by Google search to an article on ReadWriteWeb about the Facebook-AOL deal. What ensued in the comments tread is quickly becoming the stuff of internet legend.
However, behind the hilarity is a scary fact that this might be how users browse to all sites, including their banking and other more important sites. A quick search for "my bank website login" and quickly click the first result. Once they are there, the user is willing to submit their credentials even though the site looks nothing like the site they tried to reach. (This is evidenced by the fact that user's comments are connected to their facebook accounts via facebook-connect)
Preventing this scenario is pretty much out of our control and educating our users on the basics of internet browsing may be just as impossible. So how then can we ensure that users know they are on the correct web site before trying to log in? Is something like Bank of America's SiteKey sufficient, or is that another cop-out that shifts responsibility back on the user?
The Internet and web browsers used to have a couple of cool features that might actually have some applicability there.
One was something called "domain names." Instead entering the website name over on the right site of your toolbar, there was another, larger text field on the left where you could enter it. Rather than searching a proprietary Google database running on vast farms of Magic 8-Balls, this arcane "address" field consulted an authoritative registry of "domain names", and would lead you to the right site every time. Sadly, it sometimes required you to enter up to 8 extra characters! This burden was too much for most users to shoulder, and this cumbersome feature has been abandoned.
Another thing you used to see in browsers was something called a "bookmark." Etymologists are still trying to determine where the term "bookmark" originated. They suspect it has something to do with paper with funny squiggles on it. Anyway, these bookmarks allowed users to create a button that would take them directly to the web site of interest. Of course, creating a bookmark was a tedious, intimidating process, sometimes requiring as many as two menu clicks—or worse yet, use of the Ctrl-key!
Ah, the wonders of the ancients.
The site could "personalize" itself by showing some personal information,
easy recognizable by the user, on every page.
There are plenty of ways to implement it. The obvious one:
under first visit, the site requires user to upload some avatar,
and adds user's id to the cookies. After that, every time the user browses
the site, the avatar is shown.
When I set up my online bank account, it asked me to choose from a selection of images. The image I chose is now shown to me every time I login. This assures me that I am on the right website.
EDIT: i just read the link about the BoA SiteKey, this is apparently the same thing (it sounded from the name like a challenge-response dongle)
I suppose the best answer would be a hardware device which required a code from the bank and the user and authenticated both. But any of these things assume that people are actually thinking about the problem, which of course they don't. This was going on before internet banking was common - I had a friend who had her wallet stolen back in the 90s, and theif phoned her pretending to be her bank and persuaded her to reveal her PIN...
When the user first visits the site and logs in, he can share some personal information (even something very trivial) that imposter sites couldn't possible know - high school mascot, first street lived on, etc.
If there's ever any question of site authenticity, the site could share this information back to the user.
Like on TV shows/movies with the evil twin. The good twin always wins trust by sharing a secret that only the person who's trying to figure out who the good twin is would know.
You cannot prevent phishing per-se but you can take several steps each of which do a little bit to mitigate the problem.
1) If you have something like site-key or a sign-in seal, please ensure that these cannot be iframed on a malicious website. Just javascript framebusting may not be enough as IE has security="restricted".
2) Be very consistent about how you ask for user credentials - serve the login form over SSL (not just post-back over SSL). Do not ask for login on several places or sites. Encourage third parties who want to work with user data stored on your site to use OAuth (instead of taking your user's password).
3) You should never ask for information via email (with or without link).
4) Have a security page where you talk about these issues.
5) Send notification on changes to registered phone, email, etc.
Apart from above, monitor user account activity - such as changes to contact information, security Q&A, access, etc (noting time, ip, and there are several subtle techniques).
As part of trying to describe the threat posed by spyware and how to mitigate it I've been looking for information on how the various common spyware trojans currently in the wild capture password data. My best guess is that they either log keystrokes, intercept browser submissions or intercept GUI messages.
I'd like some more definitive information though and haven't been able to find it. Where would I find this sort of analysis?
Most of malwares (I mean advanced ones) are written in ASM or C++. A lot of them use Windows high level APIs to hook keyboard key pressing activities among with current window when user pressed key.
For example for keyboard activity mostly they use SetWindowsHookEx function with WH_KEYBOARD_LL hook
Also they use GetActiveWindow API in order to detect current active window's title. So in keyloggers, mostly you'll see something like this:
[Gmail - Google Chrome Browser]
testuser#gmail.com {TAB} testpassword
So the person who receives the keylogs will read it as you can see above.
Another method is injecting some specially writted DLLs or extensions in browsers, I've seen it mostly for Internet explorer, they use BHO DLLs in order to receive ALL GET/POST data, so you don't need any actively running EXE file, just a DLL which runs as you open Internet explorer and the DLL will send directly all your POST/GET data as it is to hacker's server. It's mostly done in same time and BHO doesn't store anything (mostly) and sends same POST/GET data you've sent to your bank in same time to hacker's server. But other keyloggers mostly store keylogs until it reaches a size, for example 5kb, then trojan submits the keylog to hacker.
There is some also "not so common" tricks to capture keystrokes and that is having a low level driver which runs in ring-0 (kernel mode) and captures keyboard data, it's more sophisticated and hard to detect, but also hard for hacker to use, you need another co-operative ring-3 (user-mode) application to get current window, current keyboard layout (English, Chinese, Arabic, etc.) in same time as kernel receives keyboard, because without knowing keyboard layout and window which user pressed those keys, it will be "almost" useless.
I've also seen an "unprofessional" way of capturing key strokes, that's using GetAsynKeyState API. They mostly write a loop function and they capture key events by calling this API every 100 milliseconds (for example).
So I think I've covered a lot of techniques which keyloggers use to capture pressed keys, if you have more specific question, just let me know.