The idea is that the user set his password via (presumably) secure https. The purpose of the random hash is so that you provide the legitimate email user a transient secret that must be used *in conjunction* with the password they had chosen (or some session cookie sent via https to avoid making them log in twice when clicking on the email).
So here the password is to authenticate that the original person that accesses the site, the hash authenticates a valid email account. Both together are required to verify the account is valid. This way someone intercepting SMTP doesn't get access to hijack account and someone without a valid email can't get an account activated.
eth0 being renamed to biosdevname and then 'consistent' device naming happened outside of systemd per se. It's one of the various questionable things that came along at about the same time as systemd, and systemd gets the blame for *all* of them, when it only brought some of it. E.g. complaining about binary logs, you can aim that square at systemd. Most of the other prominent rants commonly fired at systemd are either dbus, networkmanager, udev, or something else in reality.
The network device naming is one facet where they can't win. The ethX has problems, and so does the current state of consistent device naming (notably that if an adapter veers off into being enumerated by pci, it's probably a lost cause in all but the most extremely homogenous environment and doing those names is just causing more trouble than helping)
I agree that Torvalds isn't the authoritative god of all that makes up a distribution and as such his opinion is one to be considered, but no the only one.
Also he speaks to the biggest fundamental controversy, the log strategy/format. I agree with Torvalds, that the capabilities of systemd are interesting, but I personally find the bathwater that comes with it troublesome enough to not want it. That and how they engage with the community at times. A lot of the other gripes about systemd are more implementation mistakes that are unintended and often addresed, but this part is very explicitly intentional and counter arguments have been dismissed out of hand.
Sometimes you don't have a choice in an interoperable piece of software. In an aggresive world that tosses away backwards compat in the name of security, you'd either have to toss out a bunch of perfectly ok equipment because you *can't* talk to it anymore, or stick to outdated software to protect the investment, which may have unfixed vulnerabilities because the versions that fix things also dropped support for your needs.
All the known broken facets of MD5 have zero applicability to HMAC usage scenario. The only part of it that weakens HMAC is that SHA256/SHA512 are more computationally expensive.
If someone knows a weakness in HMAC-MD5, it's hard to imagine it would be related to any of the known broken parts of MD5, and thus HMAC-MD5's chances of being broken might not be so different than any other HMAC use of a hash.
Yes HMAC-SHA2 is the best choice now. Now it's not a good reason to go nuts over things that use HMAC-MD5 today.
This organization would just be responsible for verifying that software is secure
That was my assumption going in. I'm saying that 'verifying that software is secure' is a complex beast that I don't think is such a trivial undertaking. I was thinking of a company that has a 'development' team and a 'security' team, which I have experience in. The security team generally devolves into effectively black box testing of a system without understanding the real purpose and potentially fishy stuff going on internally that will pave the way to future vulnerabilites. CyberUL would be in those shoes, doing largely black box testing because there is no way they could do full code audits. Sure they can probe it or demand source code to do some analysis tools on it, but the most notorious security problems have mostly been around new discoveries about widely deployed technology that had previously *eluded* such analysis that is already prevalent in the industry.
It may be good to have a CyberUL to formalize already known best practices, but I don't think it's going to get what people want out of it.
Support for limited subset of encryption protocols is also a benefit of its own. E.g. OpenSSL still supports MD5
Which is quite important, since there are a *lot* of scenarios that still use MD5 (and HMAC-MD5 isn't even broken). So for things that need MD5 hashes even if it's not secure, you can still function, and for things that still use HMAC-MD5, you can still talk *securely*.
Well one, it's bad enough for a single company to have their 'security' teams meaningfully assess the security beyond the obvious. Good security really has to be ingrained throughout the process.
The obvious security issues that something like a 'CyberUL' would catch are generally not the issues. The problem is that once a new issue is discovered, the existing install base is not be updated. Either because updates are available but IT teams are slack, or because everyone has jumped on the bandwagon of using preloaded stuff baked into products that get subsequently abandoned by their vendor or the vendor just goes defunct.
For another, any US endorsed entity calling the shots for security faces a bad credibility problem. NIST is pretty well distrusted globally now, I don't know what would happen with this initiative.
The same could be said of pretty much every advancement. Guys with clubs are cowards because the barehanded guys don't have a chance. Guys with swords are cowards because the guys with clubs don't stand a chance. Guys with arrows are cowards because the guys with swords across the field don't stand a chance. So on and so forth.
Of the factors driving reluctance to engage in harming other people, I don't think giving the other guy a sporting chance to kill you is a good factor. As others have pointed out, without your own life on the line you may have the opportunity to be more careful about how you proceed. If you are in imminent danger of getting killed, you may be more likely to make hasty judgment calls, collateral civilian damage be damned.
That may be a valid concern, however that's orthogonal to the point about whether a pilot needs to be inside a craft or not.
Points can be made about how susceptible it would be to jamming attacks and such. However as it stands the statement that drones have no conscience is about as useful as saying a bullet has no conscience.
make it able to make dogfight decisions by itself.
I would say no to the actually firing bit. Sure have it be able to evade and retreat or adjust flight to try to get around jamming, but there's a dangerous step to let the AI take hold of the trigger.
I know the same can be said of humans, but at least we know how to contend with that reality.
HMAC is not just used in SSL. It's a commonly employed in a lot of protocols. It's an additional level of complexity beyond a 'broken' hash to compromise HMAC.
A hash is compromised if you can find a collision faster than brute force. Even if you have no control over the data it is broken.
It is more dangerously/practically broken if you can control generating two sets of data that hash to the same value. This is where MD5 is IIRC
It is even more critically broken if, given an image that you do not control, you can generate your own data to hash to the same value.
HMAC requires that the data combined in a useful way with some shared secret hashes to the given value. An attacker is missing part of the image that would require to be attacked, and that missing part is applied to the image in a way that makes it resilient to prefix and append attacks. SHA-1 and MD5 are weaker by virtue of brute force being easier in an HMAC context, but I don't think I've heard either of them as being 'broken' in context of HMAC. An example would be if someone figured out how to change arbitrary middle part of an image and have the hash work out correctly regardless of the secret data (if it collides, that might not be the desired effect, it would have to match what the image would have after being combined with the unknown key)
I don't know OSX and have no opinion on the matter, but Ctrl-F7 before tab can navigate between input fields seems weird. Why not have those commonly used keyboard shortcuts 'just work' without particular difficulty.
Nearly all the goofiness around the desktop experience in Linux is around the graphics stack. This is of course critical for desktops, but I had mentioned it above.
I go with Linux because I just don't like the Windows UI choice. I use Windows on my gaming system, but my Intel graphics laptop I just do linux. The graphics are adequate and my ability to actually debug weird stuff is better (my Windows system started hanging on attempts to shutdown, restart, or suspend and there's no peep of a clue as to what it's trying to do when it hangs).
Saying HMAC with SHA1 is 'weak' is a bit too worrisome. Even with MD5 broken, none of the breakage applies to use in HMAC as far as I know.
So yes, if you are using a new implementation, go with the best hash. No reason to chose MD5/SHA1 in a new design. However if you are currently reliant upon some use of HMAC that happens to use SHA1 or even MD5, no need to exactly panic and break things to get away from that in an urgent way.
Though you still have the issue of the fluctuation due to whimsical behavior of the populace.
Basically you have one of two issues: -A system where a designated few are given power to manipulate the whole currency, complete with how bad that can go when such power is wielded in a corrupt or incompetent way. On the upside, they can apply some manipulation to mask a transient issue that can and has sent economies spiraling into collapse if it manifested in the value of the currency directly. -A system where the currency is more fixed, 'value' subject to the whims of the general participants in the economy. Note that those whims can be and have been quite successfully manipulated by sufficiently confident/charasmatic folks (e.g. relatively few very vocal folks largely drove Gold value up not so long ago), so the potential for manipulation by a few is still very real, even if not institutionalized.
It seems in practice the latter is more destructive, though the former *feels* more wrong. There are of course spectacular examples of the first going wrong, but most of those systems are working. There aren't really any at scale examples of the latter going right in this day and age.
No, they still use the phrase 'Windows as a Service' prominently. There's no hint that means anything with respect to how people *pay* for the thing. It seems to refer to two things depending on the audience:
-Rolling release for the consumer space. No longer do consumers have to/get to decide on a particular version. On the plus side, if you were running Vista and then 7 level of functionality came along, you get fixed for no additional cost. On the down side, if you are running something 7 like and 8 comes along, you get changed to the 8 vision (8 underpinnings were great, except for 'Modern' UI and apps).
-Deferred recognition of revenue for investors. Investors want the appearance of a 'subscription' like revenue stream. MS realizes this would be suicide for an *OS*, but still has to satisfy those demands. So hypothetically a user buys the OS for $100 from his perspective. MS defers the revenue so it *looks* like the user pre-paid for 4 years of a subscription at $25/yr. Note that there's not guarantee that the user will stop using it before that 4 years is up, but the expectation is that in aggregate that'll be the useful life of that purchase (tied to the hardware device, maybe not transferrable even for retail anymore?).
Windows has made a lot of advancements, but the picture is not clear cut.
Performance: Graphics driver stack and utilization Windows is ahead by a wide margin. Otherwise Linux usually wins (though some debate can be had about scheduling behaviors). For reference, look at the Top500 list and count the Windows deployments versus Linux.
Security: This really is more subjective than objective in many ways. Windows let's you *think* you are logged in as admin without actually giving admin in a pretty sophisticated way. Given the common use case of desktop users using just one account as 'admin', this is probably one of the most important facets. Additionally the ability to hold multiple security contexts without having distinct processes enables applications to take advantage of OS privilege enforcement in a more efficient manner. On the flipside, Linux has more advanced namespace manipulation and enriched mandatory access control. There is much better framework for hard enforcement of very fine grained things in Linux.
Stability: At this point things are fairly even. MS gets a nod for more resilient graphics stack, but I'd say the quality of third party drivers is frequently lower in Windows than Linux. I get more crashes on a modern Windows system than a Linux system, but I don't think MS is to blame anymore directly. If Linux were more popular and third parties did the same BS they do in Windows, Linux would probably suffer just as badly. In this way, the GPL I think has helped Linux as a kernel greatly.
Not to mention that 1Y ago it was $650 per unit, and was almost $1000 a year before that.
So on top of a massive inflation over two years, they are saying they are so stable they predict a 200-300% deflation thanks to how awesomely stable it is...
I don't understand how anyone can testify to the stability of bitcoin with a straight face.
That's incorrect. Gold fluctuates pretty wildly with mass hysteria, compete with massive deflation and inflation. Much like bitcoin. Prior to the 20th century, when communication wasn't quite so instant and pervasive, gold did a pretty good job because it was rare for *everyone* to panic more or be more confident all at once.
So here we had a few admins and a bunch of 'normal' users. The normal users needed an admin to create a new group to facilitate sharing. With seafile, the users could create their own groups. That and frankly we hit a few bugs with sync and seafile seemed to do better.
owncloud's document preview and the plugins were a bit worse than seafile's baked in, but primarily it's just a platform for replicating and sharing file content for us, we don't really care about anything beyond that. We don't use the commercial seafile.
Slashdot Mirror
The UUID is discarded on first login. Additionally, the UUID is useless without the password/credentials.
The idea is that the user set his password via (presumably) secure https. The purpose of the random hash is so that you provide the legitimate email user a transient secret that must be used *in conjunction* with the password they had chosen (or some session cookie sent via https to avoid making them log in twice when clicking on the email).
So here the password is to authenticate that the original person that accesses the site, the hash authenticates a valid email account. Both together are required to verify the account is valid. This way someone intercepting SMTP doesn't get access to hijack account and someone without a valid email can't get an account activated.
eth0 being renamed to biosdevname and then 'consistent' device naming happened outside of systemd per se. It's one of the various questionable things that came along at about the same time as systemd, and systemd gets the blame for *all* of them, when it only brought some of it. E.g. complaining about binary logs, you can aim that square at systemd. Most of the other prominent rants commonly fired at systemd are either dbus, networkmanager, udev, or something else in reality.
The network device naming is one facet where they can't win. The ethX has problems, and so does the current state of consistent device naming (notably that if an adapter veers off into being enumerated by pci, it's probably a lost cause in all but the most extremely homogenous environment and doing those names is just causing more trouble than helping)
I agree that Torvalds isn't the authoritative god of all that makes up a distribution and as such his opinion is one to be considered, but no the only one.
Also he speaks to the biggest fundamental controversy, the log strategy/format. I agree with Torvalds, that the capabilities of systemd are interesting, but I personally find the bathwater that comes with it troublesome enough to not want it. That and how they engage with the community at times. A lot of the other gripes about systemd are more implementation mistakes that are unintended and often addresed, but this part is very explicitly intentional and counter arguments have been dismissed out of hand.
Sometimes you don't have a choice in an interoperable piece of software. In an aggresive world that tosses away backwards compat in the name of security, you'd either have to toss out a bunch of perfectly ok equipment because you *can't* talk to it anymore, or stick to outdated software to protect the investment, which may have unfixed vulnerabilities because the versions that fix things also dropped support for your needs.
All the known broken facets of MD5 have zero applicability to HMAC usage scenario. The only part of it that weakens HMAC is that SHA256/SHA512 are more computationally expensive.
If someone knows a weakness in HMAC-MD5, it's hard to imagine it would be related to any of the known broken parts of MD5, and thus HMAC-MD5's chances of being broken might not be so different than any other HMAC use of a hash.
Yes HMAC-SHA2 is the best choice now. Now it's not a good reason to go nuts over things that use HMAC-MD5 today.
This organization would just be responsible for verifying that software is secure
That was my assumption going in. I'm saying that 'verifying that software is secure' is a complex beast that I don't think is such a trivial undertaking. I was thinking of a company that has a 'development' team and a 'security' team, which I have experience in. The security team generally devolves into effectively black box testing of a system without understanding the real purpose and potentially fishy stuff going on internally that will pave the way to future vulnerabilites. CyberUL would be in those shoes, doing largely black box testing because there is no way they could do full code audits. Sure they can probe it or demand source code to do some analysis tools on it, but the most notorious security problems have mostly been around new discoveries about widely deployed technology that had previously *eluded* such analysis that is already prevalent in the industry.
It may be good to have a CyberUL to formalize already known best practices, but I don't think it's going to get what people want out of it.
Support for limited subset of encryption protocols is also a benefit of its own. E.g. OpenSSL still supports MD5
Which is quite important, since there are a *lot* of scenarios that still use MD5 (and HMAC-MD5 isn't even broken). So for things that need MD5 hashes even if it's not secure, you can still function, and for things that still use HMAC-MD5, you can still talk *securely*.
Well one, it's bad enough for a single company to have their 'security' teams meaningfully assess the security beyond the obvious. Good security really has to be ingrained throughout the process.
The obvious security issues that something like a 'CyberUL' would catch are generally not the issues. The problem is that once a new issue is discovered, the existing install base is not be updated. Either because updates are available but IT teams are slack, or because everyone has jumped on the bandwagon of using preloaded stuff baked into products that get subsequently abandoned by their vendor or the vendor just goes defunct.
For another, any US endorsed entity calling the shots for security faces a bad credibility problem. NIST is pretty well distrusted globally now, I don't know what would happen with this initiative.
The same could be said of pretty much every advancement. Guys with clubs are cowards because the barehanded guys don't have a chance. Guys with swords are cowards because the guys with clubs don't stand a chance. Guys with arrows are cowards because the guys with swords across the field don't stand a chance. So on and so forth.
Of the factors driving reluctance to engage in harming other people, I don't think giving the other guy a sporting chance to kill you is a good factor. As others have pointed out, without your own life on the line you may have the opportunity to be more careful about how you proceed. If you are in imminent danger of getting killed, you may be more likely to make hasty judgment calls, collateral civilian damage be damned.
That may be a valid concern, however that's orthogonal to the point about whether a pilot needs to be inside a craft or not.
Points can be made about how susceptible it would be to jamming attacks and such. However as it stands the statement that drones have no conscience is about as useful as saying a bullet has no conscience.
make it able to make dogfight decisions by itself.
I would say no to the actually firing bit. Sure have it be able to evade and retreat or adjust flight to try to get around jamming, but there's a dangerous step to let the AI take hold of the trigger.
I know the same can be said of humans, but at least we know how to contend with that reality.
Drones with weapons aren't autonomous.
HMAC is not just used in SSL. It's a commonly employed in a lot of protocols. It's an additional level of complexity beyond a 'broken' hash to compromise HMAC.
A hash is compromised if you can find a collision faster than brute force. Even if you have no control over the data it is broken.
It is more dangerously/practically broken if you can control generating two sets of data that hash to the same value. This is where MD5 is IIRC
It is even more critically broken if, given an image that you do not control, you can generate your own data to hash to the same value.
HMAC requires that the data combined in a useful way with some shared secret hashes to the given value. An attacker is missing part of the image that would require to be attacked, and that missing part is applied to the image in a way that makes it resilient to prefix and append attacks. SHA-1 and MD5 are weaker by virtue of brute force being easier in an HMAC context, but I don't think I've heard either of them as being 'broken' in context of HMAC. An example would be if someone figured out how to change arbitrary middle part of an image and have the hash work out correctly regardless of the secret data (if it collides, that might not be the desired effect, it would have to match what the image would have after being combined with the unknown key)
I don't know OSX and have no opinion on the matter, but Ctrl-F7 before tab can navigate between input fields seems weird. Why not have those commonly used keyboard shortcuts 'just work' without particular difficulty.
Nearly all the goofiness around the desktop experience in Linux is around the graphics stack. This is of course critical for desktops, but I had mentioned it above.
I go with Linux because I just don't like the Windows UI choice. I use Windows on my gaming system, but my Intel graphics laptop I just do linux. The graphics are adequate and my ability to actually debug weird stuff is better (my Windows system started hanging on attempts to shutdown, restart, or suspend and there's no peep of a clue as to what it's trying to do when it hangs).
In RFC land, PROPOSED standard is pretty much as far as most things get.
See:
https://tools.ietf.org/rfc/ind...
For example, nntp is 'just' a 'proposed standard'.
Saying HMAC with SHA1 is 'weak' is a bit too worrisome. Even with MD5 broken, none of the breakage applies to use in HMAC as far as I know.
So yes, if you are using a new implementation, go with the best hash. No reason to chose MD5/SHA1 in a new design. However if you are currently reliant upon some use of HMAC that happens to use SHA1 or even MD5, no need to exactly panic and break things to get away from that in an urgent way.
Though you still have the issue of the fluctuation due to whimsical behavior of the populace.
Basically you have one of two issues:
-A system where a designated few are given power to manipulate the whole currency, complete with how bad that can go when such power is wielded in a corrupt or incompetent way. On the upside, they can apply some manipulation to mask a transient issue that can and has sent economies spiraling into collapse if it manifested in the value of the currency directly.
-A system where the currency is more fixed, 'value' subject to the whims of the general participants in the economy. Note that those whims can be and have been quite successfully manipulated by sufficiently confident/charasmatic folks (e.g. relatively few very vocal folks largely drove Gold value up not so long ago), so the potential for manipulation by a few is still very real, even if not institutionalized.
It seems in practice the latter is more destructive, though the former *feels* more wrong. There are of course spectacular examples of the first going wrong, but most of those systems are working. There aren't really any at scale examples of the latter going right in this day and age.
No, they still use the phrase 'Windows as a Service' prominently. There's no hint that means anything with respect to how people *pay* for the thing. It seems to refer to two things depending on the audience:
-Rolling release for the consumer space. No longer do consumers have to/get to decide on a particular version. On the plus side, if you were running Vista and then 7 level of functionality came along, you get fixed for no additional cost. On the down side, if you are running something 7 like and 8 comes along, you get changed to the 8 vision (8 underpinnings were great, except for 'Modern' UI and apps).
-Deferred recognition of revenue for investors. Investors want the appearance of a 'subscription' like revenue stream. MS realizes this would be suicide for an *OS*, but still has to satisfy those demands. So hypothetically a user buys the OS for $100 from his perspective. MS defers the revenue so it *looks* like the user pre-paid for 4 years of a subscription at $25/yr. Note that there's not guarantee that the user will stop using it before that 4 years is up, but the expectation is that in aggregate that'll be the useful life of that purchase (tied to the hardware device, maybe not transferrable even for retail anymore?).
Windows has made a lot of advancements, but the picture is not clear cut.
Performance: Graphics driver stack and utilization Windows is ahead by a wide margin. Otherwise Linux usually wins (though some debate can be had about scheduling behaviors). For reference, look at the Top500 list and count the Windows deployments versus Linux.
Security: This really is more subjective than objective in many ways. Windows let's you *think* you are logged in as admin without actually giving admin in a pretty sophisticated way. Given the common use case of desktop users using just one account as 'admin', this is probably one of the most important facets. Additionally the ability to hold multiple security contexts without having distinct processes enables applications to take advantage of OS privilege enforcement in a more efficient manner. On the flipside, Linux has more advanced namespace manipulation and enriched mandatory access control. There is much better framework for hard enforcement of very fine grained things in Linux.
Stability: At this point things are fairly even. MS gets a nod for more resilient graphics stack, but I'd say the quality of third party drivers is frequently lower in Windows than Linux. I get more crashes on a modern Windows system than a Linux system, but I don't think MS is to blame anymore directly. If Linux were more popular and third parties did the same BS they do in Windows, Linux would probably suffer just as badly. In this way, the GPL I think has helped Linux as a kernel greatly.
Not to mention that 1Y ago it was $650 per unit, and was almost $1000 a year before that.
So on top of a massive inflation over two years, they are saying they are so stable they predict a 200-300% deflation thanks to how awesomely stable it is...
I don't understand how anyone can testify to the stability of bitcoin with a straight face.
That's incorrect. Gold fluctuates pretty wildly with mass hysteria, compete with massive deflation and inflation. Much like bitcoin. Prior to the 20th century, when communication wasn't quite so instant and pervasive, gold did a pretty good job because it was rare for *everyone* to panic more or be more confident all at once.
That is true, but gold/silver is more concrete. There is a psychological factor in concrete things.
So here we had a few admins and a bunch of 'normal' users. The normal users needed an admin to create a new group to facilitate sharing. With seafile, the users could create their own groups. That and frankly we hit a few bugs with sync and seafile seemed to do better.
owncloud's document preview and the plugins were a bit worse than seafile's baked in, but primarily it's just a platform for replicating and sharing file content for us, we don't really care about anything beyond that. We don't use the commercial seafile.