Great advice! You sound like you have a lot of experience in server security.
What is your recommendation on strong passwords? Also, should all passwords on a system be different (login passwords for different servers, email passwords, etc...), and if so, how do you keep track of all of them?
This is a good way to go about it. I use Supergenpass session (the bookmarklet version is exploitable by websites you visit) for Chrome for websites, and keys for most ssh purposes. I have a couple of strong memorized passwords for situations where keys and supergenpass aren't convenient.
I'm totally on board with having one long/strong passphrase memorized and using it to generate strong, seemingly random passwords algorithmically, and I assume that's what SHA1_Pass does. So, yes, using SHA1_Pass is probably a good way to go about it.
On the one hand, the hex password in the screenshot while quite long has only 16 possible characters. The Base64 password has only 60 possible characters to choose from (for each position) and must end with an equals sign.
The number of possible characters for each position in the original sentence is quite high (94) but in a sentence the actual likelihood of a wide range of combinations being used is quite low (unless deliberately using obsfucation).
It's a very interesting piece of software and presents a very interesting question, which I guess is this:
For a given sentence, which out of Base64 encoding, Base 32, Hex and the sentence make for the most permutations required to crack? If the answer is Base64, 32 or Hex then your tool is helping. If the answer is the sentence then your tool is impeding. I suspect (but haven't done the maths) that for purely single case alphanumeric passwords it'll be base 64, but for mixed-case alphanumeric with punctuation it'll be the sentence. Anyone care to do the sums to lock this down?
I think you're missing the point of something like SHA1_pass: A different passphrase for every site. In the case of SuperGenPass, it hashes the site with the passphrase, making a unique passphrase for every domain. In the case of SHA1_pass, I would do something like, "My wacky passphrase 123 facebook.com" and "My wacky passphrase 123 google.com", etc. if I were to use it.
The sentence is only a piece of the hashed value, while some unique thing about what you're logging into is the rest of it. So, using "My wacky passphrase 123 facebook.com" as my password directly on facebook.com would mean that anyone with malicious intent and access to facebook.com code could easily figure out that every website where I have an account is "My wacky passphrase 123 sitename.tld". Strong password failure. The one-way hashed version of that has no meaning to the sites I log in to.
So, original sentence has very low security value, while a hashed version of it (assuming a unique piece for every site or service) has very high security value, even if the actual password generated is less strong than the original sentence from a purely "number of possibilities" perspective.
Of course, if you always use the exact same passphrase, and thus the same resulting password, your math would make sense...but the likelihood of an exploit is far more likely to come from people behind one of the sites you use sniffing your password, than from a brute force attack, in either case.
As I understand it, SHA1_pass does the following (please correct me if I'm wrong or missing anything out):
* Takes a user supplied passphrase
* Makes a SHA-1 hash of the supplied passphrase
* Encodes the resulting hash in a variety of ways
I don't see where a different passphrase for every site comes in. You seem to be saying that you would append the site if you were to use it - you wouldn't need a tool like SHA1_pass to do that though.
I guess where I'm coming from is that I don't see what SHA1_pass does that provides any benefit over something like 1password or password gorilla, both of which can generate random passwords for arbitrary accounts.
Following your example, if I obtain your password on site A, then I get a hex|base32|base64 representation of a SHA-1 hash. I then put this into something like this (http://www.golubev.com/hashgpu.htm) and crack the SHA-1. I notice your algorithm for creating passwords and do the same. I'm now exactly where I would be if you weren't using your approach for a password on every site.
I appreciate that the SHA-1 element acts as an interesting intermediary, but your method for generating the password is predictable. I think a randomised SHA-1 might be better.
Author again. It should be used exactly as SwellJoe Described. The hash of "My Awesome password for Facebook!!!" should only be used on facebook.com. "My Awesome password for Twitter!!!" and so on.
The benefit of SHA1_Pass is that you never store, synchronize or backup passwords ever again. It's free, completely open-source and anyone can implement it and other software can be used to generate the hashes. Some of the password storage managers are not that way.
Disabling remote root login isn't as big a deal as it used to be - as others have said, if someone gets your administrative account you're pretty screwed anyway - and if they get your password for sudo, it's the same thing.
Other than that, it really depends on what you mean by cloud.
Root login shouldn't be your normal entrance. For maintenance stuff use sudo-capable regular user account with public key authentication. If there's some software that requires root login and you cannot do anything about it, enable root login and allow it only from the specific IPs.
Thanks for creating this and open-sourcing this great app!
One question: Does aggregates.html work? I can see that metrics are being recorded in mongodb, but it does not load the js properly to display the hourly, daily, and weekly metrics. I can get everything else to work fine (in index.html). Thanks!
Have kids or babysit? Kids are awesome negotiators, because they don't care about the other party at all, they just want to get the best deal for themselves possible. They also start from a position of weakness in most negotiations, which means they need to try some wonderfully creative strategies to get what they want.
Actually, I wonder why most adults lose that ability as they get older. My guess is that sometime in the teen years, people start caring about what others think of them, and that is poison to negotiations.
This. Having a toddler has given me a lot of practice in how to negotiate. Also, a negotiation book (The Secrets of Power Negotiation) helped me with the toddler.
A lot of your day to day activities can involve negotiating. For example, taking your car in for service/repair? Negotiate the price. Buying tires? Negotiate the price. Booking a hotel room? Negotiate. Doctor visit? Negotiate the fee. Heck, even a department store will often negotiate if you're nice.
Negotiation/Conflict Management
CSUB-Online
InSt 435 (5) or
Mgmt 430 (5)
It's online, so when I took it, there were no in-state/out-of-state fee differences. When I took it (a long time ago), the two main texts for the class were "Getting to Yes" and "The mind and heart of the negotiator". http://www.amazon.com/Mind-Heart-Negotiator-Leigh-Thompson/d...
I highly recommend the second book especially. Towards the end of class, there is a group negotiation exercise. I thought it was quite good.
Negotiations is a required class at my b-school. The material is soft. The lecture itself only lasts a short amount of the time. For the rest of the class, you just practice. Negotiate with another party (using a case study to determine your role.) The class ended after the results were tallied and the class discussed different approaches to the problem. It wasn't a tough class, but it was useful and enjoyable.
Interesting exercise. Most recruiters will talk your wage / salary down. The difference in commission for the recruiter negotiating UP from an initial offer from a company (like $75,000 vs $80,000 (what you want)) or $95,000 - $105,000 is a very neglibile difference in their percentage of the recruiters fee. This, opposed to NO recruiters fee for losing the placement because the company decides that the extra $5,000 is not worth it (AH FRUSTRATING!) Its lovely when a candidate wants $120,000 plus relocation, and, the company goes "sold." Not typical in my own experience as a tech recruiter.
Doing some negotiating that is low-stakes but has a value attached. For example, talk to a friend / sibling / whatever and offer to babysit / trade services (e.g. web design for massage) in exchange for $WHATEVER.
One thing it can buy is time, and consequently leverage.
At Demo Day, the investors will know that all the startups have some cash to last after YC, so that they don't have to rush on the first investor that comes along which should translate to better terms for the founders. Or it could just allow them to look for investors a bit later on, hopefully providing them with a better negotiating position by having a product further along or gain some traction before needing the money.
hiring engineers is not a good idea, your startup team should have enough talent to do 90% of the work. Some use of the money could be for design art work, or marketing (free swag). For example if you were planning to launch your startup on iPhone only, you can now use the money to contract someone to develop for Android, WP7, blackberry, this money can make the startup more complete at launch.
Or do you want the designers to build the blackberry app?
I think spending it on swag would be a horrible idea. I can't think of any company that succeeded because they had really great swag in the early months.
It looks really cool!, but I don't understand how it is a 24 hour shot. It just looks like a tiny planet with a house on top. Could somebody please explain the image?
(The description by the author in the post is complicated)
Think of it as a wide 360 degree panorama picture stitched from images taken at different times of the day. This would yield a wide, non-distorted rectangular image.
This one combined image was then rolled around itself in such a way that its whole bottom edge is now in the center of this "planetary" image, and its top edge is now the outer circumference of the image (the border with black).
If you're wondering why the center point of the image is not heavily distorted it's because it was overlaid with a simple top-down photo of the place the tripod was standing on.
The statistics on this infographic are misleading. It does not cost 200,000 to buy a house in San Diego or San Jose!
Maybe the average for downtown San Jose and San Diego are close to 200k, but that is the poorest area of both cities and not what should be used to compare. The green bubble on the point for San Diego should be much much smaller in radius(like miniscule), otherwise you think the 200k number refers to the entire city!
People should not be using this to make informed decisions (obviously).
I believe that they're basing this data on stats collected by the census, so you have take the city as defined by the census bounds, which aren't necessarily similar to common conceptions of what area is 'in' a city.
There are many cities in the county of San Diego. The city of San Diego (where you are suggesting that the 200k number came from) is about 10-20% of the size of the county of San Diego.
They should make the size of the bubble smaller to only cover the area of the city like you are saying.
The circle is definitely scaled correctly though, the ratio of area of the circle to population (1306300 people per 1809 pixels, or about 722 people per pixel) is within the margin of error for my numbers for new york (about 662ppl/pixel), and LA (about 725ppl/pixel).
I noticed they are using "listing prices" instead of sale prices or any kind of constant quality index to calculate their ratios. That's probably not ideal, but since price series are hard to find for homes it's at least understandable (that and it's their business model to collect listings).
I do a lot of work in this domain and the price-to-rent and price-to-income ratios for California look higher by my calculations. Using median sales prices for the broader metro area and income and rent data from the Census, I'm finding California is still quite expensive.
Do you know what that product is? If not, it's going to be a difficult slope for you. Wanting to build a product to make money vs building a product to serve the needs of a community are vastly different.
With the 200+ million gmail email addresses that Google has access to, Google can instantly become a major competitor to Groupon & LivingSocial assuming a certain percentage of gmail users agree to try it.
It seems that each large internet company has its own deals site now: Google with Google Offers, Amazon with LivingSocial, eBay with Groupon, and Facebook seems to be developing its own type of daily-deals advertising.
I wonder what Apple and Microsoft will do. Both of them probably have something in the works....
What is your recommendation on strong passwords? Also, should all passwords on a system be different (login passwords for different servers, email passwords, etc...), and if so, how do you keep track of all of them?
Thanks