Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Comment Re:No surprise... (Score 1) 114

FIPS level 3 has nothing to do with software, that is the level which requires safeguards against physical tampering - tamper-evident seals etc. Again, nothing to do with the actual operation of the software. Level 4 takes Level 3 up a notch requiring even more hardening around "the module"... but AGAIN, nothing about how your software actually USES the module. Such a thing is totally outside the scope of FIPS.

FIPS is an outdated standard. It made sense when it was created and crypto was not well understood and poorly standardized. Today it adds little value because almost all software on earth uses standard crypto libraries.

Don't even get me started on PCI, which isn't even worth the paper it is written on.

Comment Here is the #1 problem with delivery drones (Score 1) 129

Company spends $10,000 on delivery drone. Company dispatches done on it's first delivery run. Rogue actor uses $100 worth of equipment to jam all transmissions to/from the drone, removes power source, and steals it. Company is now out $10,000.

Because they are unmanned, drones are simply far too easy to lose and far too easy to steal. They are impractical.

Comment Re:No surprise... (Score 3, Insightful) 114

It is a total joke.

FIPS 140-2 ensures your algorithm is part of a standard set - big deal. It does no investigation at all as to how you use that algorithm or why you use it. If you are using AES with a FIPS-certified library, you get the checkbox. Nevermind the fact that the private key you are using is sitting in plain text on the disk.

Its the same as all federal standards - FedRAMP, FIPS, FISMA, ISO 27K. They all do *SOME* things, but none of these standards, or any intersection of them, actually do anything with regards to real secure engineering. Note, I am not even sure it would be close to practical to do this. I am just raising awareness that saying that an application is "FIPS certified" is next to useless.

Source: I have dealt with getting applications certified in all of these umbrellas, and more. It is an extremely time consuming and expensive process for all involved to get certified - but in the end does very little in terms of real application security. But it sure makes the auditors a lot of money!

Comment Re:Well... (Score 1) 449

While it is common for your card issuer to bundle them, EMV has nothing at all to do with RFID cards. Many EMV cards have no RFID chip at all.

EMV == "Chip and PIN". There is a private crypto key on the chip on the card and a two-way live handshake done at the terminal, and you must enter a PIN. No signature is used.

RFID == MasterCard PayPass and Visa PayWave. Again there is a private key on the card but there is no PIN used to guard it. Transactions done by RFID are normally limited to $50.

Comment Re:68th to 22nd and there are many to go (Score 2) 192

The fact that Swift *only* targets iOS and OSX makes it a non starter for most companies. Companies are not in the game of building an app twice from the ground up. Cross platform frameworks for apps and games are ESSENTIAL - even if the app has a different skin between iOS and Android, the internals all need to be cross-platform. Otherwise you are spending 2x the cost for none of the benefit.

FWIW, this is also why this survey is incredibly flawed. The vast majority of iOS and OSX apps are not open source so stats from Github are totally irrelevant as to what trends are actually occurring in industry.

Comment DONATE (Score 2) 282

Donate

Donate

DONATE

If everyone who posted a reply to this story donated to the EFF with their dollars in addition to their words, that would be pretty substantial in aggregate, and they could do some real work with those funds.

Donate to the EFF. They have been fighting this fight for as long as I have been alive and are one of the only groups to has maintained the fight. While I have donated to them on and off over the years, I have been lax for quite awhile. I just donated to them and challenge everyone else to do the same.

PS: And, this comes from someone not in the USA who DOES NOT get a tax break from his donation since they are not registered in my country, but who recognizes the global impact of the EFF.

Comment Re:Discussion is outdated (Score 2) 492

If you want to play with research languages and esoteric forms of programming, then don't get a job in industry, and stick to academia. No one in industry uses Pascal, D, Go, or any of these languages du-jour on Slashdot, because they lack some combination of robust libraries, performance, online knowledge bases, or all 3.

Almost all business applications and consumer-facing applications written in industry today are done in 5 languages

- Java, because of it's incredibly rich library set under the Apache project.
- Python, for anything that does not need to be compiled
- JavaScript, for Web development and Node.JS development
- C/C++, for performance oriented applications, or used with a cross-platform toolkit for Windows/OSX applications
- C# Applications that are Windows platform exclusive
- Objective C (and now Swift) Applications that are OSX/iOS exclusive

Before you villify me, yes I am not retarded and I know that you can compile and run C# applications on OSX and can compile and run Objective C applications on Windows. The truth however is, no one in industry actually does this. If you write an application you want cross platform, you do it using a cross-platform toolkit.

Comment This. SO MUCH This. (Score 5, Insightful) 492

I often feel like everyone on Slashdot is a mix of two people

- Old 50+ year olds used to the good 'ol days when you would write your own stack from scratch whenever writing an application

- 20 year olds fresh out of (or still in) college who yell "squirrel!" at everything new and shiny

The truth is, that 75% - 90% of the business applications that make the world go 'round, and make nearly every startup today go 'round, are based on Java or some complimentary technology like Node.js with Java bindings. The reason for this is simple: The Apache foundation. There are SO MANY amazing enterprise-class Java libraries available via the Apache project that there is little to no reason to ever write your own. The mantra where I work, and it should be where EVERYONE works, is before you write any plumbing code at all, check Apache first. People who roll their own plumbing code INVARIABLY end up with subtle errors they did not think of or subtle problems that will manifest themselves in 2 or 3 year when they try to scale.. and all these problems were likely already figure out long ago.

When building a woodsheed, do you cut down the trees, mill the lumber, and forge the nails? Of course not, you take advantage of modern economies of scale so you can focus on the REAL building project, not the building blocks. The same is true for any halfway competent software developer.. The days of people writing their own libraries for DB MVC, for configuration management, for network access, for parsing libraries, for thread pools.. these days are gone, and thank god. The less you have to worry about the low-level plumbing, the more you can focus on the real business problem. And furthermore, the more people that make use of a low level plumbing libary, the better and more secure and stable it becomes, for everyone.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...