How do you avoid session hijacking and other problems with remember me on logins? One thing i know is to add a md5 or the useragent, but that's isn't a very good protection in itself... is there smthng else too?
My general rule is: Do not incorporate such an option in an application where the user's login would be more important than the loss of their computer itself.
So... StackOverflow.com account? No biggie; if I lose my computer, that won't be among the things I'm really worrying about.
OTOH... my online banking account? No way I want anything on my computer beyond the mere presence of a bookmark to help anyone gain access to that account.
My opinion is that the other things are OK if you have the time/effort, but their effectiveness isn't all that great when you consider that the real, ultimate problem would be someone who has literally gained possession of their computer.
p.s.: Please consider voting this answer up/accepting it as your answer if it's useful to you
Related
stackoverflow community.
I am currently a middle school computer science teacher.
I was wondering what was the best tool to demonstrate how easy it is to crack their password. (could be a program that I can install)
I want each students to enter what they think is a "hard" password and the rainbowtable will solve it and display the time/password. (I've done my research and looked at rainbow tables)
Hopefully this community can help me :)
Thank you in advance.
P.s sorry if this question isn't posted in the correct location.
Well...I'm not going to touch password cracking algorithms with a 10 foot pole, even for an academic discussion.
But, you could demonstrate using sleight of hand by putting a packet sniffer such as wireshark (or ethereal) between the hosts and an LDAP server and just capture each of their passwords in clear text on their way down.
You could also install a keystroke logger on each of the machines and just have it simply log their passwords to a file.
Either would be "cheating", but that's another valuable point that you could make. It really doesn't matter how strong your password is if someone can get access to it. The usual way that people get access to other peoples' sensitive data is through sleight of hand and deception, not brute force.
Brute force, such as rainbow tabling a hash can still be used, of course "to break through the front door." But, if someone "leaves the window open", why go through the trouble and take the conspicuous route?
(P.S. I personally think it's unwise to be discussing cryptographic attack methods in a middle school setting. If you are going to do this at all, I think it would be very dangerous to expose the method you used. I wouldn't mention the method to any of your students at all or I guarantee you are going to inspire several of them to go running amok)
Has anyone heard of Chaperon? is it effective in preventing code theft?
Now i understand that there can be many ways if someone was to steal code and there is nothing that could be completely foolproof, so please don't give me this as an answer.
I want to know how effective this is and how does this utility/software exactly work?
Are there any other tools that are similar to this one?
It is the wrong question to ask. See Secure collaborative software development environment in the cloud
Why would you want to work with people you don't trust? The costs of organizing the control needed to make that effective are so large that your efficiency would be too low to survive in the market.
The reason that Chaperon doesn't have much competition is simply that there is no market. Start using it, go out of business fast.
One strong thing to consider when implementing any "code theft prevention" scheme is the fact that you're willingly trading productivity for security. The most productive environment for creating and debugging code is an open and easily shared one. This is why there are millions of lines of Open Source code written every year, even though most people involved aren't being paid for it.
Consider carefully whether the increased overhead and costs in terms of developer time is worth the theoretical potential for theft by one of your developers, who is already familiar with your algorithms and architecture, and could probably re-create the code if it was really something worth stealing.
Now, protecting your source code repositories from external access, and protecting your code "in transit" from people external to your development group who might be stealing it really boils down to Network Security, and you'd probably be better off posting it on serverfault.com or superuser.com
You can't effectively do what you're asking, especially in an environment where you don't trust the people working there.
A proper solution is to build a business model that is robust in the face of someone else getting the software. If as you say the “work ethics are unreliable”, you should count on the software getting spread around anyway.
Don't rely on artificial scarcity of the software – especially if, as you say, you can't trust your staff to maintain that scarcity – instead, rely on being the people who know the most about it.
I think all that can be done is monitor in situations like this. Firewall network. Deny https traffic. So users can not securely upload. Have softwares that email/log when external I/O devices are plugged.
Fire people whom you cant trust if that is an option.
I've a question about a good way to protect a bit my cocoa app from piracy. I know that this is impossible!
So, in my app I've an isRegistered() method that runs every time the user launch the app.
This is called from the applicationDidFinishLaunching: App delegate. So if this method returns true, the app continues to execute the code, otherwise an Alert appears saying that the app is not registered and there are xx day to buy a license.
This is a good way? Because, I have no experience in this.
Thank you in advance for your help!
SOLVED
First of all, thanks to everybody! I think the same thing: any copy protection can stop the piracy. I'm trying only to solve this little bug, even if I know that someone will crack my app again.
However, it's true - the best thing is to improve the app and not waste the time to try make the piracy protection more efficient.
The solution you describe requires almost no expertise whatsoever to crack. It is trivial to change your isRegistered() function to always return true. Thus, the effort required to circumvent your protection is a tiny fraction of the effort you would have to spend implementinging all the infrastructure to support users purchasing registration codes.
In other words, you're not getting a good return on investment. There is some debate over whether the return on investment implementing piracy protection (rather than improving your product) is ever good enough (because you pit yourself against people who have nothing better to do than prove they're cleverer than you).
One good way to redress the balance of return on investment is to use pre-existing code such as AquaticPrime. That way, at least you won't have spent so much time chasing rainbows :)
I am not in shrink-wrapped software business but my friend is. And his observation after 10 years of selling his product was that it makes no sense to create too sophisticated protection because always some one will hack it. You are alone and world is infinite. It is better to invest time/money in improving your software than working on copy protection.
Also keep in mind that around 10% of will never steal and other 10% will always try. Just make sure that those 80% is able to buy your product without any other mayor obstacle. Than you could ignore those nasty 10%. Actually it is a quote from Joel Spolsky IHMO.
So your solution seems to be completely OK from technical point of view and just stay with it.
it's almost never worth implementing your own anti-piracy system, because you'll almost always spend a lot of effort on something which can then be broken very easily. Rely on a shared implementation - in this case a framework like AquaticPrime (lots of people on the macsb mailing list recommend that one) - and you're effectively relying on the framework being good enough to protect your own app as well as all the others.
The code signing framework on Leopard and later allows you to sign your code such that if it's ever tampered with, it will refuse to run - see the documentation of the kill option in the manpage.
This is a good question. Having read the answers, I think what BitDrink was really getting at was this: we know that an isRegistered() function is dead simple to hack. With the understanding that any protection system eventually will be hacked, what are some strategies for writing a function that's harder to hack than an isRegistered function that returns a boolean?
Fundamentally, any copy protection system will eventually have something that looks like this:
if (program is registered)
let the program continue
else
nagging message
end
Any hacker with a copy of GDB will eventually find that first line and write a tiny little patch to strip it out. Most copy protection systems focus on security through obscurity, i.e. making that line hard to find. You can also make this system more robust by signing the binary and checking the signature, but you'll just add another hoop for the hackers to jump through. They'll eventually find your public key and change it to their own public key so they can replace your signature. However, I believe this will significantly slow them down. Leopard offers a code signing utility, but I don't know if it can be used to prevent incorrectly signed applications from running at all.
There's no perfect solution to this problem, but there are two main things to remember:
your registration system will be broken. There is absolutely no way around this.
your reigstration system is a barrier between the user and your program. You should optimize for the (hopefully majority of) legitimate users and make this as easy to do as possible.
I am trying to help a small business that has an application that could benefit from occasional (or temporary) database expertise. The problem is, this company has all their IP in this database, so they are rightfully hesitant to give someone access it.
They would typically meet and gain trust in person, but the talent pool within physical proximity to them is pretty limited. I would like to think that they could still somehow tap into the global DBA expertise though...
Even the crappiest DBA will be able to dance SQL Circles around these guys - so exposing only pieces of the database doesn't sound feasible to me, but I am hoping I just don't know how.
Anyone have any tips on how they could find a trustworthy company (or individual)? When I hire a programmer, I start them on basic stuff that if they mess up won't hurt too much. With a database, is there something that I can start with that can limit their exposure. Maybe Profiler output for analysis or something?
As the others have mentioned, NDA's are a good idea, that covers you from the standpoint of WHAT they see...
However, I can feel that you are also concerned about any potential "damage" the person could do to your database if they make mistakes. To get around, and protect from this is a bit harder, but there a few good key items that I would recommend.
BACKUP EVERYTHING before starting, this is common sense, but cannot be overstated
Provide the consultant a test environment if you are able to replicate production issues. This gives an isolated environment where testing can be done.
DO NOT limit their database access. Database issues require digging into the system, limiting their access, could actually contribute to an error rather than preventing them.
Look for references, or evidence of the persons abilities.
I provide this information as a consultant myself. I do .NET and SQL Server consulting, and I ensure that all of the above are true in my consulting cases, and I have not had a fault. Steven points out the biggest key in this all and that is all a consultant has is his reputation. Serious consultants fully understand this, and because of it will make sure that they do NOT put themselves into tricky situations.
The simplest thing is requiring all employees and contractors who see the database, or its design, to sign non-disclosure agreements. There are plenty of boilerplate ones there, and a good attorney can provide guidance on what you'd need in one with less than an hour of billing time. Everyone in the industry is used to them, and everybody understands why they have to sign them.
Of course, that's not a programming question, it's just a legal problem.
consultants sign NDAs all the time, and the good ones take them seriously because a consultant's reputation is all he has
while not a DBA, i can highly recommend this fellow as I have known him all my life ;-)
Of all the forms of CAPTCHA available, which one is the "least crackable" while remaining fairly human readable?
I believe that CAPTCHA is dying. If someone really wants to break it, it will be broken. I read (somewhere, don't remember where) about a site that gave you free porn in exchange for answering CAPTCHAs to they can be rendered obsolete by bots. So, why bother?
Anyone who really wants to break this padlock can use a pair of bolt cutters, so why bother with the lock?
Anyone who really wants to steal this car can drive up with a tow truck, so why bother locking my car?
Anyone who really wants to open this safe can cut it open with an oxyacetylene torch, so why bother putting things in the safe?
Because using the padlock, locking your car, putting valuables in a safe, and using a CAPTCHA weeds out a large spectrum of relatively unsophisticated or unmotivated attackers. The fact that it doesn't stop sophisticated, highly motivated attackers doesn't mean that it doesn't work at all. Using a CAPTCHA isn't going to stop all spammers, but it's going to tremendously reduce the amount that requires filtering or manual intervention.
Heck look at the lame CAPTCHA that Jeff uses on his blog. Even a wimpy barrier like that still provides a lot of protection.
I agree with Thomas. Captcha is on its way out. But if you must use it, reCAPTCHA is a pretty good provider with a simple API.
I believe that CAPTCHA is dying. If someone really wants to break it, it will be broken. I read (somewhere, don't remember where) about a site that gave you free porn in exchange for answering CAPTCHAs to they can be rendered obsolete by bots. So, why bother?
If you're a small enough site, no one would bother.
If you're still looking for a CAPTCHA, I like tEABAG_3D by the OCR Research Team. It's complicated to break and uses your 3D vision. Plus, it being developed by people who break CAPTCHAs for fun.
If you're just looking for a captcha to prevent spammers from bombing your blog, the best option is something simple but unique. For example, ask to write the word "Cat" into a box. The advantage of this is that no targeted captcha-breaker was developed for this solution, and your small blog isn't important enough for someone to actually develop one. I've used such a captcha on my blog with some success for a couple of years now.
This information is hard to really know because I believe a CAPTCHA gets broken long before anybody knows about it. There is economic incentive for those that break them to keep it quiet.
I used to work with a guy whose job revolved mostly around breaking CAPTCHA's and I can tell you the one giving them fits currently is reCAPTCHA.
Now, does that mean it will forever, call me skeptical.
I wonder if a CAPTCHA mechanism that uses collage made of pictures and asks human to type what he sees in the collage image will be much more crack-proof than the text and number image one. Imagine that the mechanism stitches pictures of cat, cup and car into a collage image and expects human visitor to tick (checkboxes) cat, cup, and car. How long do you think will hackers and crackers will come up with an algorithm to crack the mechanism (i.e. extract image elements from the collage and recognize the object depicted by each picture) ...
If you wanted you could try out the Microsoft Research project Asirra: http://research.microsoft.com/asirra/
CAPTCHAS, I believe should start being considered heavily when designing the UX. They're slow, cumbersome, and a very poor user experience. They are useful, don't get me wrong but perhaps you should look into designing a honeypot.
A honeypot is created by adding a hiddenfield at the bottom of the form. Because spam bots will fill in all the fields on the page blindly you can do a check:
If honeypotfield <> Empty Then
"No Spam TY"
Else
//Proceed with the form
End If
This works until there is a specifically designed spambot for your site, so they can choose to fill out selected input fields.
For more information: http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx/
As far as I know, the Google's one is the best that there is. It hasn't been broken by computer programs yet. What I know that the crackers have been doing is to copy the image and then send it to many phishing websites where humans solve them to enter those websites.
It doesn't matter if captchas are broken or not now -- there are Indian firms that do nothing but process captchas. I'm with the rest of the group in saying that Captchas are on their way out.
Here is a cool link to create CAPTCHA..... http://www.codeproject.com/aspnet/CaptchaImage.asp
Just.. don't.. There are several reasons use of captcha is not advised.
http://www.interfacegeek.com/dont-ever-use-captchas/
I use uniqpin.com - it's easy to use and not annoying for users. So, bots can recognise a text, but can't recognize a image.
Death by Captcha can solve any Regular CAPTCHA (incude reCAPTCHA), but not Speedcoin Cryptocurrency Captcha.
Death by Captcha - http://deathbycaptcha.com
Speedcoin Captcha - http://speedcoin.co/info/captcha/Speedcoin_Captcha.html