Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
An application I maintain offers a standard password reset script. My employer wants to add a tool for our support reps to set the password manually to something they pick themselves, and give the password to the customer over the phone.
Security in my application is expected to be top notch, so this sets all sorts of warning bells in my head.
Aside from the obvious no-no of allowing support staff to know customer passwords, What other security implications should I be aware of in this scenario? In the case of fraud, would this increase our legal liability?
My take on this is that you have to offer customers the ability to reset their password. Customers will forget their passwords and need them reset. Meeting the customer in person and confirming their identity is presumed to be out of the question, so it might as well be done over the phone after a human has verified the customer's identity (in some way that's deemed sufficient). Any written form of communication such as email is almost guaranteed to be archived somewhere, so having the password in that form is a bad idea. A phone conversation might be recorded too, but at least it's not searchable. YMMV.
That being said, the thing that you give out over the phone should most certainly be a temporary password that needs to be changed the first time the customer logs in with it (and preferably is only good for a short amount of time). Otherwise your staff will know the customer's password!
I can't speak to legal liability.
Since transmitting a strong random password through phone without errors is hard, support staff might gravitate towards choosing weak passwords (such as a dictionary word plus some letters) if they get the chance to do so. Also, they might write passwords down in case the customer misheard and calls back, which might result in even more people knowing the password.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I just want to know if having 2FA on your login can actually mean that you don't need to worry about it if someone steals your username and password?
I know there is a problem if someone steals your phone, and can access an authentication app like Google Authenticator or Microsoft Authenticator and just enter the app and read the generated codes. But what are the odds of anyone actually being able to get access to your phone and accessing that such an app?
I am using 2FA in most of the services I am using because I feel much safer that way. But is it worth implementing it in your own services if your encryption system is not so good? Will it be critical if someone manages to break into my service and read everyone's usernames and passwords in the hypothetical situation where everyone is using 2FA and unique passwords anyway?
A few thoughts:
Security tends to be better when there are more "layers" of it. A combination of username and password is one such layer. 2FA is another. Adding 2FA will no doubt improve your security, but you should still strive to keep your username and passwords secret. Consider what happens if someone steals your phone, but is unable to get hold of your password. Use both.
Related: Logging into a system is not the only threat; information about an account is too: What if a user does not wish it to be known that he has an account in your system? If someone can access your database of usernames and passwords and the data is published, the whole world will know who your users are; perhaps this is not critical in your case, but it can be in certain other cases, and it`s a good principle to adhere to in any case. So strive to keep both usernames and passwords secret, if possible.
I realize you already know this, but your hypothetical situation is just that - hypothetical. You should never assume that all your user's passwords will be unique to your service. Some users will do stupid things. That may not be your fault, nor your responsibility, but it is still considered good practice to do what you can to help them stay safe.
If you are aware that your encryption system is "not so good", then you should obviously try to improve it.
2FA may not always work, or may not be an option for everyone in all cases. If it is not critical to your service, you might consider making it possible to opt out of. For some customers, choosing to accept a little more risk may be worth it for a slight reduction in "hassle" when logging in. For others, this minor "hassle" may be an insignificant price for better security. In any case, you should offer 2FA as a possible improvement in security, and not as an excuse for lax security in other areas.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
From what I understand, you have to enter in all of your usernames and passwords into Mint, so I assume they are actually logging into your bank account and scraping the resulting screen to put this data into a form that Mint and others use.
How do they actually simulate the keypresses and mouse clicks? I assume banks don't like it when they do this - how do their scrapers avoid detection?
I'm pretty sure they don't simulate clicks, etc. In the end, any data that ends up on a user's page is transmitted in a response to a request. If you can figure out how to construct a valid request and then how to parse the response, you'll have the data you want.
As far as I could gather after using Yodlee for quite a while, they deal with sites in two major ways: the sites they have official agreements to work with and the sites they don't have official agreements with. For the first category of sites they, most often, have agreed upon APIs for getting the data. For the sites in the second category they reverse-engineer layer 7 communication protocols and data structures (a.k.a. screen/html scraping).
The way I understand it, Yodlee uses the OFX specification to access banks' financial information.
http://www.ofx.net/
For the banks that don't implement OFX, they use custom screen scrapers, which must constantly be updated when banks change the information that's displayed on their site.
I don't know Yodlee so i simply assume it's like "sofortüberweisung.de" where you give a 3rd party your bank login data (and depending on what you do even a valid TAN) and thus trust them not to abuse it and additionally break your bank's security regulations ("NEVER GIVE YOUR YOUR PIN/TAN").
They most likely simulate what a browser would do. As web-based banking interfaces are usually just HTML/JavaScript everyone can look at the client-side code and do whatever it does with a custom program. Since those actions are not done in a malicious way, actions which require e.g. a TAN or a CAPTCHA to be solved can be simply forwarded to the legit user who will then enter the necessary TAN or solve the CAPTCHA.
Nonetheless to say, it is really bad to use services like that. While they most likely won't do anything bad you cannot know it for sure. And your bank is damn right if they don't refund you anything if you ever get scammed by such a service.
Another solution which would be perfectly safe (as long as you are not concerned about a 3rd party knowing about your financial status etc.) would be the yodlee company making contracts with major banks allowing them to access your data after you've authorized it through some way (you can already do that on pages like Twitter - I'd never do that for bankign though but technically it wouldn't be hard to realize something like that). That would be clean and secure as it would not involve "screen-scraping" or customers entering their banking login data anywhere but on their bank's website. But I believe no bank does something like that and in my opinion that's good as there are way too many people out there who are far too trustworthy and we all know how many information they give out on Facebook & Co. Now imagine a facebook<->bank integration... M.Zuck.'s wet dreams which hopefully never become true... And even if it's not Facebook.. There'll always be companies who want people's personal data and enough people giving them out; especially if it's easy and looks secure ("I have to confirm it on MY BANK's page. so it MUST be safe - it's supported by MY BANK").
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Let's say I have designed s very important system, and this system costs thousands dollars. I want to protect my system with a serial number as I know crackers will try to edit the binary code to bypass the serial number.
I have read about using a checksum function and apply it over my binary code and check the value if changed, but again, we are talking about a condition a cracker can avoid by editing the code.
My question is: what's the most used technique to protect important programs?
I have yet to see a "protected" digital product that had not been cracked pretty quickly after its publication (or in some cases, before its publication). Sorry, but it's the reality. You have to get the revenue by making a good product. Most of those who want to use it and can afford, will pay.
There will be a few dickheads, but that's life. You better be kind towards the legit users of your software and not bully them with weird copy protection attempts that don't work anyway.
If your app is working offline, whatever checks you do (check sums, serial code validity, etc), do them often, repeating verification code, in many routines of your software. Obfuscate your code, to make reverse engineering a more difficult task, and, if you have the possibility, implement an online check, part of the core functionality of your app residing on your server, and being serviced only to those installations that you have checked server-side for valid license key. Associate the license key to some form of unique identifier of the hardware the app is running on, and if you check online, have statistics concerning the IPs that make the verification request: if you encounter more IPs trying to verify the same license key, contact the buyer and approve a list of IPs they usually log on from, whilst blacklisting any other until specific request from them, either by mail or by phone.
The most used technique is serial numbers. But your customers will have access to the code, so they will be able to bypass your serial number check, no matter how much work you put into obfuscating it.
However, if you can provide your software as a subscription-based or one-time-payment web application, then people will not be able to do this. Whether this is feasible or not depends on the type of application you're writing.
I would always recommend to build a custom software protection before applying any kind of commercial protector such as a Packer.
In any case just a serial validation and a checksum check are not going to keep crackers away.
I would recommend you to visit my new blog www.anti-reversing.com and take a quick look at the anti-piracy tips & tricks page just to have an idea about what I am talking about.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Browsing through Coding Horror, I saw this article on removing the user field from a login dialog.
It's an interesting concept albeit an old one from 2005. Nevertheless, I started thinking about it and wondered:
How would you be able to do this in a secure fashion?
If you identify the user by their password that means all passwords must be unique - yes?
If all passwords must be unique, what do you do when someone enters a password that's already in use?
You can't tell them it's already in use because that would give away someone else's login.
I can't think of a way one could implement this in a secure fashion...any ideas?
You do not identify users by password, you identify them by user name. You authenticate users by password. Just think a bit what does it mean to identify by password. I join the system, he asks me to enter my new password. I say 'foo', he says 'foo is already in use'. I say 'tyvm'', and open the login window. When prompted I simply enter 'foo' and he says 'Welcome Mr. President'...
No, there absolutely cannot be a requirement to have passwords unique, that would be a huge security hole in any system because it relies on information disclosure to function: by reveling a duplicate you disclose somebody's password. Even with name/password combinations, once you disclosed that 'password is in use' all I have to do is iterate through the list of accounts trying the password you just revealed to me, and one combination will succeed.
My first thought, which is also alluded to in the article, is to increase the password complexity requirements to avoid collisions.
16-byte GUIDs avoid collisions (every star can have 6.8×1015 GUIDs) well enough, so it shouldn't be too difficult. Obviously human-generated input isn't quite as random, but if you add in enough requirements like lowercase/uppercase/numbers/symbols/length, it might work well enough.
Well, I suppose you could look for some other piece of "uniquify-ing" data, to use in combination with the password. For a web app, this could be a hash inserted in a cookie, from a previous visit. It'd be hard to guarantee uniqueness (multiple users from a single profile on a single computer, for instance).
My bank takes essentially this approach, with my public IP address. It's a little annoying, actually. Every time my DHCP lease expires, my bank's website "un-recognizes" me, and asks one of several security questions, before I get the standard username/password screen.
Multiple-factor security uses something like this (a hardware key or hardware-provided identifier, in combination with a password).
This approach strikes me as overly clever, and clever's rarely the right way to approach security systems.
I believe you cant.
By entering your username you are providing your identity, by entering your password you are providing a means for the server to verify this identity.
Both are inherently required unless you have some other means of determining identity (IP, keycard, etc.)
Basically you cant expect anyone to believe you are who you say you are, when you don't say who you are!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm a full time software developer, but on the side I'm teaching a university course on web services. I'm going over security right now and was wondering if any of you all have had any security breaches that you could tell about (details obscured as needed) that I could share with my students. Real life stories are a lot more meaningful than made up scenarios...
Here is a story from me:
I once was customer of an online audiobook store. Beside authenticating myself with username and password, I also needed my browser to accept cookies. This wasn’t unusual. The cookie is probably needed for storing the session ID.
But I got confused since the session ID was also transmitted in the URL and I didn’t saw a reason for why there was a need for cookies. So I took a look into my cookie jar to see what oh so important information have to be stored in cookies.
Beside a cookie for the session ID there was another cookie named customer_id that obviously was designated to identify me by my customer number. I thought: “Come on, no one can be this stupid!” I altered the value for fun by changing one digit of the number (e.g. from 12345 to 12346) to see what happens.
Now guess what: I now was logged in as a different user without any further request for authentication just by changing the cookie! The customer_id cookie value was abviously not just for identification (Who am I?) but also for authentication (Am I really the one who I pretend to be?)!
The moral of this story: Always separate identification from authentication.
This may not be what you had in mind, as there was no information compromised, but it still very much a web security issue.
http://www.crime-research.org/library/grcdos.pdf
That is the classic story of how internet security guru, Steve Gibson's, site was attacked by a botnet. It is a very interesting story and would certainly keep the class engaged. I know this story got me more interested in web security.
I could not find the original post of that pdf on Steve Gibson's site (grc.com), but I had a copy on my computer and was able to search for it and found it at the given location.
I also recommend going to grc.com and listening to the "Security Now!" podcasts:
http://www.grc.com/securitynow.htm
You will almost surely hear some stories in some of those podcasts.
Hope this helps!
The European Identity Conference (EIC 2009) in Munich will be featuring a case study on SOA security that will have the information you seek.