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
If I write a login system for a client who later gets hacked can I or my company be held accountable for whatever damages they claim?
Excuse me if this has been asked already. I did a search and found no relavant answers.
I recommend that you consult an attorney for this kind of a legal question. This is a technical forum and not a place for legal advice.
The software warranty and the courts is a murky area. It really would depend on what warranties you provide. Typically with software there is an explicit denial of any warranty and that the software is a best effort however in the US anyone can sue anyone else for almost anything. Just trying to defend a suit can be financially devastating which is why housing contractors have a tendency to have multiple incorporated companies which carry the liability for homes built and insulate the contractors personal assets from any suits.
You do not say what your industry is. Different industries will have different standards. For instance in point of sale there are the PCI standards from VISA, etc. on security standards for card account information.
Depending on the industry and the kind of security breach, yes you could be liable.
You really should get the services of a security specialist and a lawyer in your software target industry to discuss this and other legal questions.
The main point to remember is that when there is a breach especially one with financial repercussions, more than likely your customers will look for someone to blame. So you really want to have something in writing that indicates who is responsible for any liability due to a breach. And as part of that there probably should be some description of what would be considered minimal acceptable security practices on the part of the people using the software.
That said a minimal set of necessary practices that you should follow would be something along the lines of the following. I make no claim these are anywhere complete as I am not well versed in computer security.
Reduce privileges and what can be done as much as possible. This hopefully will reduce the amount of damage that may arise when someone breaches the system.
Always assume that input may be tainted so watch out for standard intrusion practices such as SQL Injection or URL modification in the case of REST or other unexpected modifications to input data.
Never assume that just because something is hidden that it will not be found and exploited.
Log everything possible so that when a breach happens, the forensic team will have the data they will need for an investigation.
Passwords are a fairly poor authentication mechanism so you want to beef them up as much as possible. So password aging is important to force passwords to be changed. Password difficulty checks should be used so as to encourage more complicated passwords that will vary from change to change. Passwords should never be maintained in clear text nor should passwords be transmitted in clear text. Encryption is your friend and helpmate.
Biometric information can make for a better authentication mechanism however some people may have features that do not work well with some types of biometric systems such as people whose fingerprints do not work well. Some type of unique device may also be used such as an authentication code generator that is synchronized to a central device or perhaps a central device which sends an authentication code via a text message to your phone when you attempt to log in.
Using the system probably should require a password to be re-entered at the time of some sensitive action especially with systems which may be accessed from a public terminal.
Make sure that it is easy for someone to log out so that they will be more likely to do so as part of closing out a session.
Make it easy for users to be disabled by a supervisor and provide a way to make it easy for a supervisor to generate a report of who has access to what, when have they used their access, and what did they do when they had access.
Borrow a page from Gmail and other e-mail systems to notify the user whose account it is as well as a manager or supervisor via e-mail any access that seems unusual or of a sensitive nature. Also notify via e-mail if any user account type changes are made such as password change along with logging this type of activity.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I need to prevent reuse of password hash by another user,
for example if a user can create his hash (knowing the password of curse)
if he gained access to the database and replace someone else's hash with his, he will be able to log in as that user
I was wondering if adding the id of the user to the hash will be good practice, if not, what else can I do?
thank you.
If someone can substitute the credentials in your database, and if this is the only thing that determines access to your system, then, yes, the user can cause your system to accept whatever password he chooses.
This is one important reason why many production systems ... used within a company ... and many of the back-side "plumbing" layers of public-facing systems ... do not use passwords of any sort to handle authentication or authorization. Instead, they use "trusted third-party authority" techniques such as LDAP (OpenDirectory) or Kerberos. No one is "whispering magic-words to one another" at any point.
In this scenario, both "authentication" (verifying who the requesting user actually is), and "authorization" (establishing what he can do) are not handled by logic within the systems themselves: these tasks are delegated to a centrally managed corporate authority. There is the concept of a "single sign-on." There are no "passwords" to steal. Even if the system requires the user to respond to a personal-challenge, e.g. to enter a password as part of the procedure, the central authority (software layer) manages everything: providing the challenge, interpreting the response, knowing that a correct response was timely given, and so forth.
These are robust technologies with peer-reviewed, trustworthy implementations that are also cross-platform and industry standard. They're very comprehensive. When you "swipe your badge" to get into your building every morning, they're probably what actually unlocks the door. They can be accessed by PHP, and/or by whatever web-server service is running your PHP application.
I'm currently developing a system which has a functionality where clients can view details of their purchases/renewals/etc by supplying a PIN "number".
A PIN is being used instead of login information because of the type of clients we're targeting. The PIN is printed on documents sent to them.
The view shown when they supply the PIN does not reveal highly sensitive information such as credit card etc, but less sensitive one such as product name, type, price, barcode, repairs etc.
The issue in question is the PIN. I opted to using a random 5 character PIN (0-9, a-z A-Z) - case sensitive.
I'll be removing some homoglyphs ('I','1','l','0','O','rn','vv'), so the actual number of combinations is actually lower.
I've got a couple of questions about this:
Is this practice acceptable?
Should I write a lockout mechanism to "ban" traffic from IPs with a large amount of failed attempts?*
Should I write an error checking system (similar to Luhn's algo in credit card numbers)?
*Should I make use of a captcha system?
As for the CAPTCHA and lockout - I'd go for the CAPTCHA, and delay 1) the clients that fail CAPTCHA, and 2) invalid logins: before checking, sleep 1 sec on 1st attempt, 2s on second, 4s third, 8s on subsequent. This won't inconvenience normal users too much, but it will slow down an attacker significantly. No matter what you do, people will get it wrong - no need to ban them outright.
The checksum - might be useful as a 6th character for detecting typing errors, not for security.
As far as the password strength goes, this is a weak password - I wouldn't use this as the only form of authorization for anything stronger than "sharing pictures of lolcats" - consider a longer one, or your clients might even accidentaly access each other's data (and they tend to get really upset when that happens: "you mean that anyone could see my data like that?!").
A PIN is being used instead of login
information because of the type of
clients we're targeting. The PIN is printed on documents sent to them.
Very strange, but yeah could write it like this. I think you should really reconsider if it is really necessary. But if I understand you correctly you sent the document via snailmail? For example Isn't it possible to send the user a PIN and next have them sign into openID(LightOpenID). I would lock it down to just Google's OpenID provider because these accounts are "safe". This way you have added another level of security. Also Google uses captcha to verify account(make it
"safe").
Is this practice acceptable?
I think it is acceptable, although very strange.
Should I write a lockout mechanism to
"ban" traffic from IPs with a large
amount of failed attempts?*
I think you should write a lockout mechanism should because brute-force hacking password is already easily accomplished, but brute-force hacking a PIN can be done without any effort at all. Although I don't think you should do it via IP, because the end-user could sit behind a router and then he would be blocked. Also hackers could have a botnet to perform these kinds of attacks.
I read today about HashCash thanks to stackoverflow.com and I also found it very interesting. Maybe you could use that to protect yourself against attacks.
Should I write an error checking
system (similar to Luhn's algo in
credit card numbers)?
I don't think so.
Should I make use of a captcha system?
The only true way to prevent automated attacks is CAPTCHA's, so I think you should. Google/Twitter/etc aren't using CAPTCHA's because they are user friendly, but because that is the only working way to stop automated attacks. If you would implement my system that PIN with OpenID from Google then you can skip this step, because Google already has you covered.
First of all, ask not only for the PIN, add something simple the customer knows, like with snail mail systems where you're often ask for your ZIP-Code. That sorts out people that do not know the somehow "shared secret".
The captcha, if it's not annoyingly hard makes sense as it helps to reduce "guess" attempts by bots. As Stefan mentioned, banning by IP is problematic because of shared IPs.
You could also implement some kind of "tar pit" when form posts are wrong based on your error checking, e.g. you delay the processing of incoming connections. A simple algorithmic error check helps you to avoid a useless database lookup of the given PIN.
1) Yes, depends on target audience though.
2) Sometimes it makes sense, sometimes it won't work due to how the system is used, and how many clients are on a shared IP number.
3) What value would it add? Won't that just help people trying to find a working PIN?
4) Depends on target audience, and what kind of captcha.
yes but it depends on the value of the information,if the information value is hight and you think that someone may try to break in you should consider additional protections
It may be a good idea if the information you are protecting have an hight value,in this case you must warn the user that he have a limited numer of possibilityes,create also a log file to monitor failures on code typing and consider that if the user is behind a NAT a lot of user may use the same ip(all the user on an office or in school for example,also connection like fastweb use one ip for a large group of people) so don't block the ip for a long time(15-30s every 3-5 fails should be enoght to avoid brute force attacks,you can double it every time the user fails a second time)and,most important,block only the code immission not the whole site.
it's not needed but you can implement it,as i sayed it also depend on the value of the information
it's a great idea to avoid proxy and crawlers but i recommend something different: use an image with a question like " five plus 2 =" or "what's the color of a red apple?",they're a lot more hard to understand by crawlers but a lot more easy for users.
I recommend also you use mt_rand() to randomize the pin(a lot more efficient than the default random,it's statistically correct random and it's integrated in php as default),the homoglyphs removal should be a good way to avoid error typing but i may recommend also to create a longer code with separators like
AXV2-X342-3420
so the user should understand that's a code and easly count how many character are left or if he entered the wrong code.
I may avoid case sensitive pin because upper case characters are more easy to read and some user will simply paste it lower or upper case only even if you write clearly that the code is case sensitive.
The axiom "If you're going to roll your own security, you've already failed," applies here.
For your 5 character [0-9, A-Z, a-z] pin, you're generating less than 8.27 bits of entropy (64 310 = 2^n). [fixed]
It will take less than one day (a 1,000 guesses/sec, which is very slow) for an attacker to break your system. Is that acceptable? Maybe for trivial systems where bypassing security has very little impact.
Should I write a lockout mechanism to "ban" traffic from IPs with a large amount of failed attempts?
IPs can be spoofed.
Should I write an error checking system (similar to Luhn's algo in credit card numbers)?
That would actually decrease the number of bits in your entropy, making it easier to break into your system.
Should I make use of a captcha system?
If you feel you need the exercise. Captchas have been broken and are useless for anything other than as a speed bump.
Update
Unfortunately, there is no cut-and-dried solution for computer security, as it is still an immature (undermature?) field. Anyone who says, "Oh, do this-and-this and you'll be fine" is skipping one of the most fundamental issues around security.
Security is always a tradeoff
The ultimately secured system cannot be accessed. On the other end, the ultimately-accessible system has no barrier to entry. Obviously, both extremes are unacceptable.
Your job as a software developer is to find the sweet spot between the two. This will depend upon several factors:
The technical expertise of your users
The willingness of your users to put up with security
The cost (time and money) to implement and maintain (i.e., a more sophisticated system will generate more support calls)
The impact a breech would have on your users and company
The likelihood of a breech: are you the US Department of Defense? Visa? You're probably under attack now. Bob's Bicycle Shop in Ojai, CA is on the other end of the spectrum.
From your question, I take it that you're effectively generating their "password" for them. What if you flipped it on its head? Make the pin their account and the first time they log into your system they have to create a password* that is then required from then on.
*Yes, if this is a bank, then this is not a good idea.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I've started reading a book on PHP security (but it's really all theoretical not so much practical) and have it in my plan to read Chris Shiflett's and Schenider's blogs, but does anyone know of a formal course that I can attend or even get a certificate that proves I know how to write secure PHP code?
Edit: I got a lot of answers, some of which don't answer my question. So I'm quoting ircmaxell's comment because it really hits the point.
While I agree with the cert not
mattering (and that finding
vulnerabilities is the best way to
learn), I'm not sure that answers the
question. How should one go from not
knowing anything about security to the
point where they can do audits to be
able to find vulnerabilities
What I want to add though is that while I agree that experience is more important that certification, certification is not unimportant. It's a quick proof that I know more than the high school hobbyist programmer from India who's charging $30 for a full project.
http://www.zend.com/services/certification/ is a good one.
Before you take that exam you might want to have a look at:
httpOnly Cookies
cross-site request forgeries
OWASP development guide
SQL injection
rules for processing credit cards
SSL/HTTPS
cross site scripting (XSS)
Cross-site request forgery
The Google Browser Security Handbook
The Web Application Hacker's Handbook
Writing secure code spans more than just PHP: good code, proper code is language agnostic. While there are nuances in each language, there are a base set of principals to learn that are transferable no matter what you write in. It's best to learn those core values and then learn about the specifics of the language. Basic knowledge of cryptography, good database design, proper memory management, and operating system principals will give you more insight to security than just being certified in PHP security.
When it comes right down to the point, writing secure code should be a part of any programmer's skill set.
http://www.zend.com/services/certification/
I highly recommend Chris Shiflett's book. I think it should be required reading for all web developers, not just PHP dev's, as the principles, attacks and defenses outlined are applicable to all web languages. It's also a quick read but would give you a firm grounding in web app security IMHO, negating the need for a course. The chapter on security in the Zend Certified Engineer study guide is also good but covers the same ground as Shiflett's book.
There was the OWASP Certification Project, but from what I can tell it's not active anymore (although some of the content linked still appears to be active).
While not PHP specific, there's also the GIAC Certification. It's targeted towards general security as opposed to language specific techniques (from what I can gather anyway)...
There's also the Software Security Institute... I have no background with them, so I can't really vouch, but it appears to have what you're looking at.
Edit: After some reflection:
Honestly, I don't see the point in certificates. If you want to attend training, great! But all that a certificate does is prove you were able to pass a test. It doesn't say anything about what you know or your capabilities... Get real world experience, that's worth more than any certificate any day of the week. Get involved with open source projects (especially from the security front, a lot need help there in my experience). Get involved with OWASP. Gain some real world experience, attend conferences and user groups to continue learning. It'll be worth 10 times as much as the certificate...
Get a CVE number for a PHP project. If you can't find vulnerabilities in PHP code is what matters, having a certification doesn't mean a damn thing.
In order to understand how code can be insecure I suggest Installing Damn Vulnerable WebApp. You should also look at real world vulnerabilities such as the ones found on The Whitebox. The blog and shop where PHP/MySQL projects that where abandoned because they are so insecure. The challenges are difficult security systems found in the wild, however they too are very insecure. For some offensive PHP security reading I suggest A Study In Scarlet.
We're in the middle of developing a e-commerce application that will be used by our customers on a pay-monthly-plan.
We have thought a bit about offering encryption of all personal data that is stored in the database, to make our application a notch safer to the final consumers.
The encryption would be handled completely transparent in both front and backend and make sure that even if someone would gain pure database access, it would be impossible to decrypt the personal details of the final consumers without the encryption key.
Is this common sense, or are we taking on a too big bite to chew compared to the increased safety this would add to the final customers?
I might be out of my depth here, as I'm not a security expert, but here's a few questions that come to mind:
What are the chances of an attacker gaining access to the data?
Does the data contain anything confidential?
What could an attacker stand to gain from accessing the data?
What could you, or your company, stand to lose if an attacker gained access to the data? It's not just the data, it's potentially your reputation too.
How much will it cost to implement?
What are your legal obligations with regard to customer data?
If data are encrypted using a single global key, how will you keep the key safe?
If the key is really safe, how will you use it to encrypt and decrypt data?
If data are encrypted using multiple keys (perhaps one for each customer login), how will you recover data if a customer loses their key/password?
If you are able to recover customer data, how does that affect its safety?
What access will computer repair technicians, sysadmins, etc., have to your database server, and how will that affect data security? (It's not just about external hackers).
What are the performance effects of encryption and decryption?
What other mechanisms, like firewalls, physical security and employee vetting can be put in place?
Here's a quote from the UK FSA Your responsibilities for
customer data security (pdf):
Getting data protection wrong can
bring commercial, reputational,
regulatory and legal penalties.
Getting it right brings rewards in
terms of customer trust and
confidence.
My answer is: Sometimes. I've worked for a few companies that employ e-commerce solutions. Security and Encryption need to be better than what the information is worth. Names and address not as "valuable" than say credit card numbers and transaction information. The setup I'm most familiar with is one where all general CRM data - names, address, etc - that is typically fetched more frequently are stored on servers databases - plain text - and the security for the server is increased (Firewalls, patches, etc) and the script accessing the database is of course - secured to the best of the developers knowledge.
Credit card, transaction information, the real down and dirty "information people would want to steal" was contained on a server - encrypted, secured, and only available via local lan. The encryption key was on a second server access to these machines was dictated by a rotating authentication key that only a third server knew. The two key/data servers were unaware of each other. When purchases were made the third server - accessed by a forth - would "magically" make it all come together to complete the purchase.
It's a very convoluted, and terrible answer. In short - protecting/encrypting the very sensitive data is a must is you wish to ensure your customers protection from theft - but ALL information may be an unnecessary overhead for your application. Security is only worth what the data is worth to the thief.
Doing this you lose many of the relational database advantages (searches, reports for the business intelligence and so on).
Furthermore, if you store the keys you just add a layer of 'security': an attacker will have to obtain the keys in order to read the data, but if he has full access to your database, he probably has access to the keys' repository, too (as must have access to that repository the frontend and backoffice applications).
If you instead give the users the responsibility to store their own keys, you lose the possibility to restore the data in case an user lose his key.
Get the real sensible information, put it in a separate server, put as much security as possible around it and acces the data only when needed.
In my opinion the main threat of your approach will be the (false) sense of security that the encryption will give. Sensible data must be treated with all the due caution in storing, but also during elaboration and use: put your money in good system administrators, prepared software engineers and periodical security assessments, if your business require.
Why is it safer?
You need to store the decrpytion key in order to provide that data to the user - it's not really relevant that its only held in the 'front-end' system - in order to get to the back end a hacker must get through the front end first.
You also eliminate a LOT of the searching functionality.
You have to do a lot of coding to imlpement this.
You're placing much heavier demands on the system (i.e. more hardware cost, poorer performance).
IMHO your money and time would be better spent on improving security elsewhere.
C.
I understand the mantra of "don't roll your own" when it comes to site security frameworks.
For most cases anyway.
I'm going to be collaborating on a site that integrates text-messaging into the system.
I'd like to use an existing, well-tested security framework to protect the users data, but I need it to also protect a users phone number as well.
I wouldn't want to be the one responsible for a list of users cell phone numbers getting jacked and spammed.
What suggestions can the community offer?
Note that techniques applied to passwords aren't applicable here. You can store a password salted and hashed (although the value of doing so can be disputed), but that doesn't work for phone numbers.
If someone jacks your server, they can do anything the server can. This must include recovering the phone number, but doesn't include recovering the password if it's hashed well. So the phone number is just a particular case of protecting confidential data.
If phone nos truly are the only sensitive data in the app, then you could look at walling off the part of the app that sends the texts, and asymmetrically encrypting the phone nos. In a different process (or on a different machine) run an app that has the key to decrypt phone nos. This app's interface would have maybe one function taking an encrypted no and the message to send. Keep this app simple, and test and audit the snot out of it. Either hide it from the outside world, or use authentication to prove the request really came from your main app, or both.
Neither the db nor the main part of the app is capable of decrypting phone nos (so for example you can't search on them), but they can encrypt them for addition to the db.
The general technique is called "Privilege separation", the above is just one example.
Note that phone nos would generally need to be padded with random data before encryption (like salting a hashed password). Otherwise it's possible to answer the question "is the encrypted phone number X?", without knowing the private key. That may not be a problem from the POV of spammers stealing your distribution list, but it is a problem from the POV of claiming that your phone numbers are securely stored, since it means a brute force attack becomes feasible: there are only a few billion phone nos, and it may be possible to narrow that down massively for a given user.
Sorry this doesn't directly answer your question: I don't know whether there's a PHP framework which will help implement privilege separation.
[Edit to add: in fact, it occurs to me that under the heading of 'keep the privileged app simple', you might not want to use a framework at all. It sort of depends whether you think you're more or less likely leave bugs in the small amount of code you really need, than the framework authors are to have left bugs in the much larger (but more widely used) amount of code they've written. But that's a huge over-simplification.]
Since you need to be able to retrieve the phone numbers, the only thing you can really do to protect them (beyond the normal things you would do to protecting your db) is encrypt them. This means that you need to:
Make sure the key doesn't leak when you inadvertently leak a database dump.
Make sure your system doesn't helpfully decrypt the phone numbers when someone manages to SQL inject your system.
Of course the recommendation of not rolling your own still applies, use AES or some other well respected cipher with a reasonable key length.
I’m pleased to announce the release of hole-security system for PHP
This project stands for bring to PHP the kind of security that is provided in Java by Spring Security the formerly Acegi Security System for Spring. It’s designed to be attractive to Spring Security users because the philosophy is the same. It’s an unobtrusive way to add security to a PHP site. The configuration is made using substrate IoC/DI as Spring Security use Spring IoC/DI.
An example configuration ship with the framework and can be used like this:
$context = new substrate_Context(
'./path/to/hole-security/hole-security-config.php'
);
$context->execute();
$hole_Security = $context->get('hole_FilterChainProxy' );
$hole_Security->doFilter();
Just be sure that the bootstrap code of the framework is executed before the bootstrap of the MVC of your choice.
WebSite:
http://code.google.com/p/hole-security/
Documentation:
For the moment you can use reference documentation of Spring Security where it’s apply. You can get a general idea using the Acegi Security reference documentation because hole-security use the same way of configuration, but keep in mind that it’s based on Spring Security.
License:
It’s released under Apache License Version 2.0.
Features:
hole-security brings an pluggable security system where you can adopt the security requirement of your environment. Currently there is a very simple security system because it’s on the first release but with the base foundation that it brings you could suggest or request for new features to be added to the project.
Currently Features:
In memory dao authentication as a proof of concept, you can switch to your preferred dao or implementation that get’s user data from database or wherever you store it. In futures release an PDO based implementation will be created.
Configured filters for be applied to url patterns. Url path matcher can be plugged to, currently it ship with a ant styles path matcher.
Authorization Manager can be used in your application to decide wherever or not do something, always obtaining the reference from the substrate context.
Shared Security Context accessible from any code of your application if hole_HttpSessionContextIntegrationFilter is applied. You can use this context to save information related to the session without use the session object directly.
You can use a custom login page and customize it according to the hole_AuthenticationProcessingFilter configuration, or customize hole_AuthenticationProcessingFilter according to your custom login page.
The default password encoder is plain text, without encoding. Futures releases will have implementations for MD5, Sha based, Base64 and others related encoding. You can create your own password encoder and get configured.
All the objects are loaded as required, if something like a filter it’s not used for a request would not be loaded. This increase the performance of the application
There are others features related that hole-security have.