91–100 of 120 posts
Earlier quoted context omitted.
If you simply sent the SMS as soon as someone enters their login credentials instead of requiring another button to be pressed, it would make your system a bit less annoying.
That's good feedback. We have the extra step there now because some people actually prefer getting a call rather than SMS to retrieve their code.
Earlier quoted context omitted.
> It's not true two factor authentication as you need to depend on the network and protocol between namecheap and my phone. That's rubbish. 2FA means 'something you know and something that you have'. What you know is your account credentials, what you have is your phone.
I don't think you understood my comment. SMS is not something "you have". You have your phone, the SMS is sent (presumably from namecheap, or from a third party service) through the network and arrives at your phone. This means at any point between the sender and your phone anyone who has access can know what your "two factor" code is. If you use true TOTP, i.e. Google Authenticator, then the code is generated via a…
and they don't have your account credentials, that's the other half of the two factor approach
Hey all, Teddy from Namecheap here. Happy to answer any questions here or at ted@namecheap.com. As always, we advise turning on 2-factor authentication on your account.
Why did you have to bring up the specific "CyberVor" incident that has been called out as bullshit by several people in the security industry?
http://krebsonsecurity.com/2014/08/qa-on-the-reported-theft-...
https://www.schneier.com/blog/archives/2014/08/over_a_billio...
As to why it may be on-topic here: the activity reported by NameCheap in the OP lines up pretty well with the reports of a large collection of compromised accounts in the hands of a criminal group.
The question for us, as technologists, is what are we doing about this? 2FA is nice, but not the end all, be all. OAuth has largely failed to gain any reasonable traction. Using Facebook login means Facebook gets to track me as I move around the web. Our users reuse passwords, primarily due to the proliferation of dozens or often hundreds of online accounts that a single individual has. We can't expect people to use…
> Where are we with replacing the password? The state of the art of the technology, in my opinion, is GRC's SQRL: https://www.grc.com/sqrl/sqrl.htm However I think you have captured something essential in the idea that Mozilla Persona "failed to catch on", and it wasn't, as far as I can tell, for technical reasons. The real problem is that any change from the username/password system has a cost (in programmer hours,…
I know this can be hard/impossible in some situations. I've lost those battles for things that are much more trivial than replacing large parts of the authentication system. However, if you keep beating that drum and take any opportunity to push that goal, you can sometimes create the time to work on something like this.
Are your customers requesting some kind of compliance (SSAE or something of the like)? Use that as leverage. See the recent news (or not so recent higher profile Sony hack news)? We should really address some of our shortcomings.
The problem then becomes, what is the market pushing towards so that you can help push that forward. Right now there isn't a clear answer, solutions keep dying on the vine.
It seems like an API to check compromised account / password combinations against a database of breached accounts could be useful. Websites could check users aren't reusing a compromised password either at account creation, or as a one-time check as existing user log in.
The concept of securely checking the hash of a chosen password against a database of known compromised credentials hosted by a trusted 3rd seems like a reasonable addition layer of security to me. I'd love to hear counter-arguments.
Earlier quoted context omitted.
I do exactly that, using keepassX. Single use, complex passwords that I change every two months, stored in a shared encrypted database. What exactly is hard about it?
keepassX seems to be a local application: how do you use it on mobile, or when you're not at home? Also: if the database gets corrupted, you lose access to all services; if you have backups then it's a little less safe; if the main password for the database is strong you may forget it (or need to write it down somewhere outside the system); if it's not strong it's not safe.
Earlier quoted context omitted.
I do exactly that, using keepassX. Single use, complex passwords that I change every two months, stored in a shared encrypted database. What exactly is hard about it?
keepassX seems to be a local application: how do you use it on mobile, or when you're not at home? Also: if the database gets corrupted, you lose access to all services; if you have backups then it's a little less safe; if the main password for the database is strong you may forget it (or need to write it down somewhere outside the system); if it's not strong it's not safe.
Earlier quoted context omitted.
I do exactly that, using keepassX. Single use, complex passwords that I change every two months, stored in a shared encrypted database. What exactly is hard about it?
keepassX seems to be a local application: how do you use it on mobile, or when you're not at home? Also: if the database gets corrupted, you lose access to all services; if you have backups then it's a little less safe; if the main password for the database is strong you may forget it (or need to write it down somewhere outside the system); if it's not strong it's not safe.
Earlier quoted context omitted.
keepassX seems to be a local application: how do you use it on mobile, or when you're not at home? Also: if the database gets corrupted, you lose access to all services; if you have backups then it's a little less safe; if the main password for the database is strong you may forget it (or need to write it down somewhere outside the system); if it's not strong it's not safe.
I cannot say for Android, but if you keep kdbx file on a Dropbox, you can access it with iKeepass iOS app
For sensitive sites like this, users should not be given the option to use the same username/password as other websites: The username should be issued by the site in the form Sally379687 or Fred965912
What Namecheap do is better - two-factor authentication. usernames are not meant to be secret, and forcing users to look up a username as well as a password is going to be annoying. Off-topic, I switched to Namecheap (from GoDaddy) a couple of years ago, and have been impressed. Things like two-factor auth and being aware of and publicising this attack are all signs of a good corporate citizen doing things right.
Giving the user the option to use poor security is like a bank that lets its customers decide what bank vault to install, then blames its customers when they are robbed.