There are plenty of companies that pay good money for red team exercises, and even have their own red teams (Microsoft has a very highly rated one for example). So if breaking in to systems and networks is what interests you, you can do it legitimately, make good money doing it, and even get sponsored training doing it. SANS has a whole track of courses for red team training.

Thing is, you don't get called a hacker in popular media when you do that since the term "hacker" is used to mean someone breaking the law with computer related things. You are an Information Assurance/Information Security professional. Your skills are the same as what they call a hacker, even your methods, the difference is you have been hired.

Now combine that with the fact that the US has more functional law enforcement than Russia and does at least make some attempt to squash cyber crime and is it any surprise we don't see as many in the US?

Password resets don't send plain text passwords. They send a link that can be used to reset the password, a link with a short life generally.

That aside you think it is easy to pay off someone at Google to access e-mail? Try it. What you'd discover is that first most people are fairly moral, you may not be, but most are but second that places like Google have some pretty series security controls in place. A random employee can't just go and access someone's mail. I don't mean they aren't allowed to, I mean there are controls in place to keep them from doing so. Such a thing is monitored and requires authorization. You'd need to compromise more than one person, and that's pretty hard, certainly more than a "mild challenge". Particularly given that your target it a password reset for some random person's account.

You seem to be applying 20 year old thinking to the modern IA landscape. Yes, back in the 90s it might have been easier to compromise someone at the local ISP that had all of 10 people working at it and no security controls at all to get in to the mail server. Well part of the changing world and the "cloud" nature of modern services is that's not your target anymore. By and large mail is hosted by big providers, who have some of the best blue and red teams in the business working for them. They are hard targets.

While e-mailed password reset links are not the best way of doing security, they are plenty good enough for the value of what they are protecting. The resources required to compromise such a thing are way in excess of the value you'd gain. So people aren't going to try.

Well first off forgive me if I don't believe your "I'm such a l33t haxor" stories without a bit of proof. I have encountered more than a few people in my career who have supposedly done all kinds of nifty shit, yet have trouble doing even the most basic IA related tasks.

Second, things have gotten more secure than since the Internet started. Source routing is something blocked on almost all networks, switches have replaced hubs (and switches are hardened against things like ARP poisoning now), most systems and networks have stateful firewalls sitting on them, and so on. What worked in 1995 is not very likely to work today.

However the biggest of all is as I noted in my first post: E-mail is generally encrypted between provider and person today. The biggest e-mail platforms, Gmail, Office 365, etc do encryption to the endpoint. When you check Gmail, be it via web browser or your phone, Google encrypts the session with TLS and your browser/app decrypts it. That means any data theft on the target's network or the ISP is out, it is encrypted.

So you are then left with the e-mail host, the company sending the mail, and maybe the transit providers supposing those companies don't encrypt e-mail between them (which they often do). If you really think you can hit Google, well then let's hear how that would go. Lay out the theoretical framework for how you'd get in to their systems to be able to monitor data in transit.

So no, sorry, this isn't an easy task to accomplish. You'd be far more likely to succeed in attacking the target's computer (as ever) in which case crypto doesn't matter since it is decrypted on their system. Of course neither would a reset e-mail since you could just capture the passwords directly.

I know there's this idea that anything not encrypted is super vulnerable but really, then about what you are saying: How to you mount such an attack? Suppose that someone requests an account reset from Amazon and it is going to their Gmail account. Where do you propose to intercept the message? You think you can realistically hack in to the servers or network at either company? If not there you'd have to get in to one of the tier-1 transit providers. These are some pretty hard targets. Other than that the only thing you could target is the lines themselves. Of course it is a bit difficult to physically tap fiber, in a conduit, and is a bit conspicuous.

It is far less feasible to intercept plain text traffic than many geeks make it out to be. It is not impossible, a state actor can do it, or the ISPs themselves of course. But for J. Random Hacker? Pretty close to impossible. Particularly if you are talking e-mail which these days is normally only plain text between providers, and is sent encrypted to the end user. Getting to tap that traffic would be very difficult, and I'd argue someone that did would ahve higher value targets than a password reset e-mail.

It probably varies state to state but in AZ, your car is listed on your insurance. While the liability insurance is for you operating a vehicle, and applies even if you drive another car, your car is still listed on your insurance paperwork. It also helps determine the rate. If you have a high performance car, you are going to pay higher liability insurance than someone with an econobox.

So if you found a car driving around, and couldn't find a record for its insurance, good chance the owner is uninsured. It is possible that they are and just neglected to add this particular car (though that could mean the policy wouldn't cover them, which would make them effectively uninsured) but more likely they don't have insurance.

Not saying I support this spy cam crap (particularly since a private company is running and as with speed cameras they'll try to game it) but it would be something where if you run a car's plate and it comes back as not in the system 99%+ of the time it is being driven by an uninsured driver.

Look the metric prefixes up: Giga, tera, etc are base 10. Giga means 10^9, not 2^30. They always have, they predated widespread base 2 usage. The standard SI prefixes are for base 10 as that's one of the big ideas behind the SI system is using base 10 for all units.

Now there are base-2 prefixes that have been introduced, those are Gibi, tebi and so on. If you want to talk base 2 orders of magnitude, you use those.

However using regular base-10 SI prefixes makes sense since basically everythign else in our computers uses that. When a processor says 3GHz it means 3 billion cycles per second, not 3,221,225,472. When a network is "gigabit" it means 10^9 bits per second, not 2^30. When we say DVDs are sampled at 48kHz we mean 48,000Hz not 49,152Hz. It makes sense to display our storage likewise. About the only area where the base-2 prefixes make sense is RAM, since it is actually sold along base-2 boundaries.

There are lots of things in the world with stupid names that are not accurate tot heir actual traits for various reasons. However when it specifies a given item then it makes sens to KEEP USING IT rather than to try and change things and screw people up.

An area you see this all the time in is ammunition. Many, many bullets have names that don't match their actual size. For example .380 auto isn't .380 caliber. The bullet is .355, the case is .373. So no matter which measurement you are using, it is wrong. However the round is called .380 auto, so we keep calling it that because people know what it is.

If you really care about isolation, like the kind we are talking about for SIPRnet and so on then you need to use data diodes and controls.

A data diode is a hardware device that only allows transfers in one direction. That way you can make sure that when you are bringing data in to the network, no egress can happen, and such. They are very specialty, and very expensive.

However more important than that is proper controls. That means policies and procedures that are followed rigorously. You have to make sure that people are extremely careful with how data is moved from one network to another and what data is moved. You need a process that specifies things like who can decide data to be moved, who approves it, who reviews it, how this is all done and so on.

If this is really important, well don't try to do it yourself based on some posts on Slashdot, you need to hire some experts. You also need to spend lots of time in the design and planning stages, you need to careful consider and document how everything will be set up and all the controls in place.

The reason they might not bother in Phoenix is most of the time, it isn't a problem. Also it isn't a problem for the bigger jets with bigger engines, it seems, just the small ones. Well those are a somewhat new phenomena. 20 years ago if you wanted to do a jet a 737 was about as small as they got. You either used that or went with a prop plane for really short routes.

The last big expansion to Sky Harbor was in 1989, before those little regional jets were a thing.

While HEVC is probably going to be useful in the future, since it does offer good compression and the licensing is likely to get sorted one way or another, VP9 is useful NOW. Google will send you videos in VP9 format if it can since not only is VP9 Google's format, but it gets better per-bit quality than MP4/AVC. Well given that Youtube is, by far, the big name in video hosting for the 'net, makes sense to support it. On top of that, Netflix has started making use of it as well. They are the very biggest commercial streaming service. So between the two it is a massive amount of use.

I can't see why you'd want to add HEVC, which is brand new, still having licensing issues and thus has next to zero adoption before VP9 which is already a major force. I mean shit even Edge supports VP9 these days. Safari and IE are basically the only browsers that don't these days (and IE is deprecated).

When you take something that wasn't designed with security in mind and try to expand and adapt it, you have a lot of issues. Better to start with something designed for the purpose it is being used from the start.

HTTP is a good example. It was designed as a stateless protocol for transferring text documents with markup. We now rely on it to do stateful transactions for things like shopping carts online and this has lead to tons of security issues since you have to hack on state to a protocol that isn't designed to support it using things like cookies. It would be much more secure had it been designed from the ground up to handle stateful transactions with people.

IP is another great example. There's all kinds of shit in IPv4 that is completely stupid from the perspective of a protocol used on the Internet. Like source routing, where you can specify the routers that a packet must go through, or the fact that you can just claim to be from any IP you want. This is a bad design for a global communications network. However it is that way because IP wasn't designed for a global communications network, it was designed for an ARPA project and it grew. IPv6 fixes a lot of this because it was designed later, around how IP is actually used these days.

Also talking about Xwindows is funny because man you wanna talk security risk, X is a huge. If you have an X server that talks on the network any system on the network can just draw to your local display, and you have no easy way of knowing that it isn't your system. Someone can phish passwords in a very hard to detect way using it. Now of course most distros are smart enough to block remote X using the firewall, and you do something like tunnel it over SSH. However that is a hack, it is putting up barriers around something insecure. If those barriers are bypassed, the insecurity is still there. Better if it were designed secure from the ground up. Then you still put the barriers in place as well so that you aren't relying on any one level of security.

Discontinuing the use of older protocols is a good idea for security, when possible. It isn't always possible, of course, I mean IPv4 is still far and away the most widely used IP spec. But you stop using them when you can (and indeed modern OSes will prefer IPv6 when they have both available).

The reason big government contractors get so much work is not because most government agencies would prefer it that way. Most would rather do things in house. any efficiency arguments aside, it makes their little empire bigger. Rather it is because there is pressure at the top to do business with contractors who, unsurprisingly, are big donors.

Particularly since cellphones as they actually were/are, meaning phones that work with individuals radio "cells" and move between them need computers to work. They don't have to be amazing computers, but they need some computer logic to handle dealing with dynamic frequency assignment and handoff between towers.

That one piece of a technology, even an important piece, existed at a given time doesn't mean the tech could happen. Many devices require a confluence of a number of technologies before they can happen.

Smartphones are an example. They aren't particularly a novel idea, we've seen shit like them in sci fi for a long time. However to actually be a thing on the market we needed a lot of shit:

--Processors had to get fast enough at a small enough size
--Displays had to get small, light, and low energy
--Batteries had to get sufficient energy density
--Silicon based storage had to evolve to usable levels
--We needed wireless digital communication
--We needed the Internet (or something like it to have something worth connection to)

Without any one of those things, you don't have a workable smartphone. That they started to rise to prominence when they did isn't some amazing stroke of genius or luck, it was because the various technologies had reached the needed point.

Google's short support is also amusing to me since they love to snipe at Microsoft about security issues, yet the security situation on Android is garbage.

When we bring someone on, they do NOT get root/admin to critical servers their first day. They have to be off probation first, which is 6 months where I work. Even then, credentials for things are not on a document. That is just asking for them to get lost or stolen. They are given on a wallet sized card, written specially for that person, and they are instructed to keep them safe until memorized.

The reason is, of course, to prevent fuckups, as well as to make sure we trust them fully. The idea of giving someone full access to critical stuff on day one is stupid. Shit it sometimes takes more than a day for them to get access to e-mail and all that just because of all the other things they need to do.

This is 100% on the company. Have working backups, CHECK YOUR BACKUPS, and don't give a new hire a sheet with access to your critical data.