|
Even 10 years ago, mapping software was still incredibly expensive and difficult to use. Maps cost tens of thousands of dollars to make, and to share them, you had to print and distribute hard-copy versions. That’s all changing very quickly. The maps of today are mobile, intuitive and fueled by a rapidly expanding catalogue of data to which laypeople — sometimes unknowingly — contribute. What happens when old-school cartography meets new-school technology?
|
|
|
|
|
In today's era of advanced persistent threats, spear-phishing attacks, social engineering campaigns, and drive-by attacks, are endpoint security solutions performing well enough? The NSS Labs report suggests not. "Most vendors lack adequate protection against exploits," according to the report. As a result, "based on market share, between 65% and 75% of the world is poorly protected, and 75% to 85% in North America is poorly protected." It is an army bred for a single purpose: to destroy the world of men. They will be here by nightfall.
|
|
|
|
|
This is a fairly surprising result. Other comparisons I've seen in the past showed a much smaller gap between the most and least effective products; and placed MSE only slightly behind the most effective AV scanners. Even there the ones that performed better than MSE by an amount that looked better than just statistical noise were all much more intrusive.
Has the landscape changed that much over the last few years; or was the design of this test just very Kapersky friendly?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
That's a good question. The article includes a link to the study itself. I only scanned over the study, so won't comment on its validity, but they did document the testing methodology, including the specific vulnerabilities tested.
My layman's take: Kaspersky, Norton and Mcafee do this as a core business. They seem to take different approaches and, as a result, excel in different versions of the tests.
The threat environment does changes quickly and constantly. It could be that Microsoft is simply not keeping up, or got distracted by the Windows 8 launch (which they probably need to ship a new product for).
Director of Content Development, The Code Project
|
|
|
|
|
Desktop Windows has tiny buttons, menus and controls that are generally too small for finger manipulation, and TileWorld is filled with gestures that make sense only on touch screens. If you install Windows 8, you’ll have to learn both environments, like it or not; you can’t live in just one environment or the other. So the question arises: how are you supposed to operate TileWorld if you have a nontouch computer? Answer: There are mouse and keyboard equivalents for the touch gestures.
|
|
|
|
|
Yesterday, the Kickstarter funding closed and the target of $750,000 was reached ($898,921).
Kickstarter Page[^]
Now they just need to get after finalising and shrinking the boards to finished spec. More things to play with...
May the cores be with you!
|
|
|
|
|
Hi all,
I wanted to share a tool I recently developed. Over the years I've gotten so sick of manually typing concatenated strings and / or Stingbuilder objects. Last week I decided I'd had enough. I created a tool that automatically generates concatenated strings and Stringbuilder code:
www.buildmystring.com
Enjoy. I'd appreciate any feedback as well.
|
|
|
|
|
So, let me get this right. You created an account, you post a single message, pushing a link to your site, to effectively advertise something you have created. Regardless whether it is free or not, that is spam in my books!
If you had been smart, you should have created an article, talking all about why you decided to come with mystringbuilder, what its pro's and con's are, what performance metrics there are and also showing some sample code on how it all works.
|
|
|
|
|
I think that's a little strong. At least it's free. It would have been better if he'd posted in the free tool's forum.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
You should post your tool here[^] in the Free Tools Forum.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
My apologies, I thought this was the appropriate forum. I will look at the freetools forum as suggested.
|
|
|
|
|
|
If you're a web developer, you've probably had to make a user account system. The most important aspect of a user account system is how user passwords are protected. User account databases are hacked frequently, so you absolutely must do something to protect your users' passwords if your website is ever breached. The best way to protect passwords is to employ salted password hashing. This page will explain how to do it properly.
modified 29-Oct-12 21:42pm.
|
|
|
|
|
Good Article 
|
|
|
|
|
Great article, agreed. But he doesn't cover when to hash in a web app.
If I enter a password on a webpage, shouldn't I hash the password before I send it to the server?
If I retrieve the salt into the webpage from the server first and then hash the password before sending to the server, doesn't that have security implications too?
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
If the hash would be calculated at the client, then the salt is needed at the client. When logging in, the user name has to be sent to the server, and then the salt would be sent back for that user, regardless of the password. So anybody would be able to retrieve salts, which would render them useless.
Wout
|
|
|
|
|
Exactly my point. So, you'd need to do something else between client and server to secure the account id and password.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
Ofcourse, you need SSL to secure the password transfer. But even with SSL it wouldn't be a good idea hashing at the client because anybody could get anybody else's salt.
Wout
|
|
|
|
|
Salts are not meant to be secret. That's the beauty of salts. They are only used to prevent rainbow attacks and are not there for additional secrecy (as the article also mentions by the way). So it's no problem to publish the salt of every user account.
|
|
|
|
|
Ah yes, you are most definitely right, thanks for correcting me!
Wout
|
|
|
|
|
The following is the response I received from the article's author, after asking the same question via email:
----- Start Email Response -----
Hi,
Here's a copy-pasted email I just sent someone who asked a related question:
------
Even if you are hashing the password on the client side, you still have
to hash on the server. Because if you just hash in the browser, then the
hash "becomes" the password in the sense that the hash value is all an
attacker needs to get in to someone's account. If a bad guy hacks into
the database storing all of these values, then he'll have immediate
access to every account.
So regardless of what you do in the browser, you still need to hash on
the server.
[ the original sender was worried that looking up the salts would let an
attacker test if usernames are valid without knowing the password ]
Anyway, if you do hash on the client side too, you're right that you
really don't want to let an attacker test if usernames are valid. Since
you're still hashing on the server with a random per-user salt, it's OK
to sacrifice randomness for the client-side salts. I recommend combining...
1. The username.
2. A website-specific string (e.g. the domain name).
...to make the client-side salt. It's not guaranteed to be unique (e.g.
domain changes ownership), but it's very likely to be. It's good enough.
Another thing to consider is that not all users have JavaScript enabled
in their browser (I don't), so whatever you do, the system should fall
back to emulating the JavaScript hashing on the server if the user isn't
running scripts in their browser.
-----
I'll add this to the FAQ or to the main article since it's very
important to get right!
Thanks!
havoc
----- End Email Response -----
|
|
|
|
|
Yeah, I had already sent an email to them. It's the one he copy-pasted to you.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
Thanks for the feedback. I got a few emails about this so I added a subsection to the page explaining it. It's under the heading 'In a Web Application, always hash on the server' if you want to read it in HTML, but I'll copypaste it here so readers don't need to hunt it down.
Here's what I wrote:
If you are writing a web application, you might wonder where to hash. Should the password be hashed in the user's browser with JavaScript, or should it be sent to the server "in the clear" and hashed there?
Even if you are hashing the user's passwords in JavaScript, you still have to hash the hashes on the server. Consider a website that hashes users' passwords in the user's browser without hashing the hashes on the server. To authenticate a user, this website will accept a hash from the browser and check if that hash exactly matches the one in the database. This seems more secure than just hashing on the server, since the users' passwords are never sent to the server, but it's not.
The problem is that the client-side hash logically becomes the user's password. All the user needs to do to authenticate is tell the server the hash of their password. If a bad guy got a user's hash they could use it to authenticate to the server, without knowing the user's password! So, if the bad guy somehow steals the database of hashes from this hypothetical website, they'll have immediate access to everyone's accounts without having to guess any passwords.
This isn't to say that you shouldn't hash in the browser, but if you do, you absolutely have to hash on the server too. Hashing in the browser is certainly a good idea, but consider the following points for your implementation:
- Client-side password hashing is not a substitute for HTTPS (SSL/TLS). If the connection between the browser and the server is insecure, a man-in-the-middle can modify the JavaScript code as it is downloaded to remove the hashing functionality and get the user's password.
- Some web browsers don't support JavaScript, and some users disable JavaScript in their browser. So for maximum compatibility, your app should detect whether or not the browser supports JavaScript and emulate the client-side hash on the server if it doesn't.
- You need to salt the client-side hashes too. The obvious solution is to make the client-side script ask the server for the user's salt. Don't do that, because it lets the bad guys check if a username is valid without knowing the password. Since you're hashing and salting (with a good salt) on the server too, it's OK to use the username (or email) concatenated with a site-specific string (e.g. domain name) as the client-side salt.
|
|
|
|
|
We send the password salted as well as a challenge for logging into our Silverlight app.
|
|
|
|
|
Hold on:
To create : Take a random salt + password and hash. OK I understand.
To validate : Take the random salt + password and hash and check against the stored.
This does not compute... There are 2 random salts here... so 2 different hashes? Unless the salts are stored... and if your system has been pwned, your salt is pwned too.... And so back to square one...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
