Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Surprising display of ignorance... (Score 2) 284

Last I checked, the Federal Government didn't run any of the root nameservers so I can't see any way they could be considered to belong to the US (as opposed to the private companies that own them). Not that owning the roots would mean much, since all they do is identify the (privately-owned) nameservers belonging to the various (privately-owned) registries that control the top-level domains. The only TLDs owned by the US Government (ie. the US Government operates the registries for them) are .gov and .mil, and the changes to IANA won't change how those two registries operate.

And amusingly the politicians have it backwards: ICANN already manages IANA, the change will be to remove IANA from ICANN control and make it an independent authority in it's own right. IANA was put under ICANN control in 1998, after the death of Jon Postel who basically had been IANA up until then (a controlling authority for assigning IP address blocks, well-known port numbers, AS numbers and other technical identifiers was absolutely necessary for the Internet to function, and since nobody else was doing it Jon essentially arrogated to himself the authority to handle it).

Comment Re:It's a pity... (Score 1) 126

HTTP has had this forever: challenge/response authentication. There's one problem with it though: it requires storing the plaintext password on the server so it can be used to encrypt the challenge to check against the client's response. I don't know of any challenge/response algorithm that works with one-way hashes of passwords.

Comment Subnetting and isolation (Score 1) 277

My approach would be to dump IoT devices in their own dedicated subnet and exclude that subnet from forwarding across the router. That reduces the exposure to just the router, and I can monitor the iptables logs for dropped packets to/from that subnet that represent attempts to do something suspicious. Configuration doesn't have to be hard, instead of plugging devices directly into the router's switch you plug devices in to external switches, connect those switches to router ports and set each port to what kind of devices hang off it. That'd control the VLAN setup to give each kind of device (WiFi, LAN, IoT) it's own virtual interface. Configuration for the firewall, DHCP, DNS etc. follows from that (you may not want to allow the IoT subnet access to external DNS, for instance). This takes a bit to set up in the firmware, but the DD-WRT/OpenWRT firmware all the major router manufacturers seem to use for their consumer routers has all the tools and then some and once the user interface is there using the functionality isn't that hard.

Comment White House hesitation (Score 1) 199

The White House is hesitating over making any accusations along these lines because they know full well that if you make those accusations you'd better be able to back them up and the evidence to back them up is almost impossible to get. We may know that the Russians are behind it, but I doubt we've got the evidence to actually prove it to any acceptable standard and if we go off making official accusations without being able to prove them we're going to look like fools.

Comment Recycling fee (Score 1) 166

I don't know about elsewhere, but in California when you buy any sort of large electronics (TV, computer, monitor, etc.) there's a recycling fee added as a line item on the receipt to cover recycling the device when it's discarded. Recyclers in California should be getting paid for every device they take with money that's already been collected for that purpose. Maybe that recycling fee needs to be increased and applied nation-wide, with payment going only to those recyclers who actually recycle the equipment and can prove it.

Comment Anomalies (Score 3, Insightful) 91

Pokemon Go will probably follow the same path as Ingress has. Most players will be casual, but the really dedicated will be really dedicated. They'll probably introduce something akin to Ingress' Anomalies, which'll be big cash cows as players treat them as a holiday splurge-type thing.

Comment Simple or disposable apps (Score 3, Insightful) 163

This'll work fine for very simple apps, ones that only require standardized functionality. But then, with an app like that, do you really need to develop a custom one for any reason other than branding/appearance? And it'll work for disposable apps, ones that do the current job but don't need to be maintained or enhanced down the road. That's been true forever, it's why spreadsheets and word processors had macro languages so secretaries and accountants could do simple operations and calculations without needing to have the programming team get involved. But the moment you start dealing with an app with complex functionality that has to be changed, enhanced and extended over time, that's when you'll discover that you need software engineers. It's the same reason anybody who can grab a hammer and saw can cobble together a sawhorse that'll work for one job, but you need someone who understands architecture and construction to build a house that's expected to last for decades.

Comment Not strictly Excel's fault (Score 5, Informative) 349

Those conversions look like cases where the column type during import was left at "General" instead of being set to "Text" as it should have been, telling Excel to try and infer the actual type from the format of the column's contents. It's an awkward situation where the user should be telling Excel what the data type for each column is, but it's not strictly Excel's fault for doing what the user told it to do. IMO Excel should be either changed to not have a default type and to not allow an import until the user's selected a type for each column, or it should throw up an error if it infers different data types for a column for different rows.

Comment Not yet (Score 2) 140

They won't automate software development until they come up with a system that can handle creating correct software from incomplete and partially erroneous specifications which don't remain constant between the start of development and delivery. At best they'll be able to automate some of the tedious boilerplate coding.

Comment Software needs to be written for reuse (Score 3, Informative) 61

Big problem here: a lot of software where the functionality could be reused can't be reused because it wasn't written for reuse. It'll have a lot of instance-specific code scattered throughout, for example logging functions that're specific to the system it was first written to run in. The result is it's easier and faster to write it from scratch than to try and remove the instance-specific code from the original source to make it suitable for use somewhere else. An open-source policy doesn't need just a mandate for reuse, it needs a mandate for making software reusable at the time it's written. That, unfortunately, is something any developer can tell you is really hard to get management to agree to.

Comment Re:Voter, not ballot, not secure (Score 1) 182

That's easy to check. During an election you pick a sample of random precincts, set their actual ballots aside and in their place submit an identically-sized set of ballots which are randomly-generated but known. Have those random ballots created and checked/counted by independent groups so it'd be infeasible for any one entity to control both the vote-counting software and the random-ballot generation process. If the reported count for those precincts isn't exactly identical to the known count, there's been tampering with the counting software. Then you can submit the actual ballots for those precincts as a correction, replacing the random ballot counts, and proceed as usual.

Comment Voter, not ballot, not secure (Score 2) 182

The problem isn't so much that the ballot itself isn't secure, it's that the authentication of the voter isn't reliable so the identity of whoever cast the ballot isn't secure. The only ways to make that authentication reliable involve encoding the identity of the voter into the cast ballot, which blows away the whole idea of secret ballots so nobody can confirm how you voted.

It's possible to do it, but you'd need a) a state-issued smartcard with a unique key-pair assigned to that specific individual capable of encrypting and signing arbitrary blocks of data, and b) a front-end system that'd accept the voter-signed ballot, verify the signature and contents, strip the voter's signature and replace it with one from the election authority, and this system would have to be trusted not to record anything tying voter identities to ballots and verifiable so that anybody could confirm that not only was the system actually trustable but that the running software was generated from the verified code. That's a non-trivial system to set up.

Comment Sure, go ahead (Score 1) 207

In these companies' position, I'd respond "Sure, we'll provide a way to block infringing content. You'll merely have to present a judgment from a court of competent jurisdiction stating that that content has been found to be infringing. We aren't a court, we're not going to hear cases and make rulings like one.". When the whines start, I'd go "Oh, you want it blocked because you allege it's infringing? OK, we can do that. We'll block any content that anyone alleges infringes on their copyrights until presented with a court ruling saying it isn't infringing. But again we aren't a court, we will not get into the business of hearing cases and making rulings on whether the evidence supports the allegation or not.".

Comment Non-sequitor (Score 4, Insightful) 150

The recommendation doesn't make sense. Yes, your phone may not always be in your possession. That would rule out software authenticators too, since they reside on the same phone that may not always be in your possession. Even dedicated hardware tokens may not always be in your possession, they can be lost or stolen just like a phone. So if not being always in your possession is the criteria, then all of the NIST's recommended methods fail to meet it.

As for VoIP lines, yes they can be intercepted. They do however share one characteristic with cel-phone lines: they don't normally share a path with the network connection being authenticated except possibly at the user's ISP and computer (if the VoIP line terminates on their computer as opposed to their cel phone). That limits the ability of a single attacker to intercept and alter both paths, which is the central facet of what 2FA does.

Ultimately the only secure 2FA is a dedicated hardware token that requires biometric authentication to function. Anything less than that is insecure, the question being merely whether the insecurity reaches the point of being unacceptable.

Slashdot Top Deals

Some people carve careers, others chisel them.

Working...