DTMF activated question and answer phone message. i.e. you record a message "Please dial the answer to this maths question to be connected; what is 25 + 17 ? Dial this into the phone now." You setup a simple pin that then actually starts the ringer on the phone when entered.
With a phone address book that will bypass this for known callers and numbers (and maybe recent callers that passed). Not really innovative but effective enough. Solution should be simple/cheap/one-chip-digital.
You can then extend this to have the phone dial back a configured number (free phone, 800 number) with the DTMF of 1 in 100 numbers that call you and fail the test.
Of course this shifts the problem to simply pay more money for cheap labor answering challenge questions but the only way to defeat this use of the telephone network is to make it economically nonviable.
This same problem domain as SPAM email, we only needs to make every sender incur a cost to send and CPU power can be that cost, just implement hashcash inside SMTP protocol and the receiver gets to decide how hard (computationally) the problem is, allow the client/sever to exchange cookies to setup good will and reputation over time with many transactions. SPAM problem solved. Now we just need a compute mathematical algorithm that works where one end can create a maths computation problem and compute the solution (by knowing all the data) in very short amount of time, but then hand the problem to the other end to solve (by removing some information) and make is scalable exponentially and iteratively to it keeps working a CPU power gets better. Sure botnets can give them this CPU resource but now the infected user will notice when their CPU is being maxed out and probably get it cleaned sooner!
I think he is saying... HTC has been a succesful company over these past 6 years and they will also be producing handsets for lower cost and just as high quality as Nokia's handsets are expected to be. Yet HTC has not put all their eggs in one basket but is still able to perform better as a business (i.e. maintain sales and see growth).
It is true that Samsung is trouncing over HTC in the very short term right now but I do not expect this position to stay as-is, HTC will fight back after working out what the problems. Especially when they broaden their available OS on handsets through WP. Maybe Samsung is getting better marketing right now especially in light of Apple's actions, any publicity is good publicity right!
The thing is I can not see Nokia making a useful recovery many "business" people prefer their iDevices now they have already become entrenched in business now. The Microsoft and Nokia partnership looks perfect on paper for this market sector but I think they have been too slow to capture it. The only hope is in these users become disillusioned with their iDevices and wanting to try something different, but I suspect many of them will go back to iDevice right after as WP8 won't actually be that great and their children won't think it is cool enough phone.
I can not at all say (in my opinion) that Nokia has been a sucessful company these past 6 years, I can't find a measure by which to make such a claim. I've purchased Nokia's year after year since 2000 but the E6-00 is likely to be my last. I own an N900 and would have been an owner an N950 or N9 if they had only released it via offical support with warranty channels in my country, not grey import only (9110, 9210, 3210, 6230, 6630, E71, E72, N900, E6-00) to name the models I remember owning. Farewell Nokia I'm happy to let other people be "first movers" on your new platform and tell us all how great it is, but it is going to take a couple of generations of handset and good reviews for me to consider it seriously. After looking a Win8 on desktop I think you have much work to do yet.
You are searching and removing. The snippet Linus quoted is only removing. It is common to already have a pointer to the entry being removed. To suggest we have to walk the list again would pollute cache with all the extra memory being loaded just to save a branch (for any list with more than 3 items I'll have the branch thanks!).
And if you walking the list anyway, the branch 'if(prev)' cited in the supposid 'bad example' is not necessary as it is relevant only for the first iteration of the loop over a single linked list. So you'd test the special first entry case (for 'list_head') and then have a loop that is branch free.
I can only think that Linus did not explain the point well enough to warrant such a detailed cross examination we are making here.
You mean 'converted to GPL' only on a re-release and redistribute ?
This presumes the user has access to the source code of the LGPL work in the first place. The user can not convert to GPL if they don't have the source code of the LGPL work, since thy could never honour their own obligations. A LGPL user can not demand source code from the redistribution point they received a binary works.
Why not NDIVIA just wrapper the API symbols in new NVIDIA Copyrighted code that is also GPL and re-export new symbol names.
This extra "shim" module is now free for use by the NVIDIA blob the link against since it is both compliant with GPL and since they are the Copyrights holder they can provide special license back to themselves for their binary blob.
I find it funny that symbols can have licenses on them, in that all NVIDIA needs to do provide a crappy implementation of the same API mechanics to prove to a court the use of the API symbols is not tied to a single implementation of those symbols. Since you can now theoretically interchange between two competing implementations, the GPL one included in mainline kernel and the proof-of-concept one NVIDIA created for the court of law.
Most users will like the convienence of a single password model, but this time that password never leaves the device you are using. Still at risk to keyloggers just like before.
You could if you wanted secure your own secret keyring using a mixture of methods, such as a combined smartcard, password and biometrics. The biometric code unlocks data on a smartcard, the smartcard provides part of the data to the browser and the password entered into the computer completes all the necessary information needed to gain access to the keyring (that maybe stored on smartcard or on computers).
But the point is you get to decide how secure you want to make your keyring, you no longer have to hope the website you are using is understands how to do things securely. Also each website by default will have their own unique key and it is infeasable to brutre force the authentication.
Well you should be using port 587 (with or without SSL via STARTTLS command). Maybe one day they will also block port 465 (for the same reasons as port 25). But I can't see them ever blocking 587 as one of the expectations of that port is that you must authenticate to send anything. I've seen some mobile devices default to port 587 already.
Running a mail transport agent (i.e. a system that routes email like Sendmail or MS Exchange) on the end of a charagble per Mb network is a bad idea of everyone.
The sender might incur high costs to themselves when they get their recent outbreak of malware on their portable device.
The receiving email systems have no way to correctly identify the sender is genuine (i.e. not a spammer) or build a rapport with them. This is because mobile use of Internet is usually a via a one-way NAT from a dynamic/random IP. There are also no identying marks to relate one client to another. So in short you are a bad sender of email to a 3rd party that is looking to reduce their risk of SPAM.
While I don't like the idea of such blocking. I can understand the reasons for it. It is best you send all your emails from the mobile device via a system with a static IP and an accountable systems administrator. That could be orange's mail service but it can also be a 3rd part SMTP service using STARTTLS on port 587 Orange won't stop you.
The project you cites have zero downloads (this week). Come back when you've fixed all the bugs and the rest of the world is onboard.
Until then I'll keep using Java as I don't seem to run into the same difficulties you seem to have.
I'm sure realtime does matter but I can stil code in C/C++ for that and the resulting work can still run inside the Java VM in complete harmony. I'm sure you will find it hard to find people suggesting you write your video codecs in Java.
For the bigger picture where a collective project can consist of over 1000 modules with over 200 teams all able to collaborate, inspect, review/debug and see-inside each others modules and then on release day have it deploy and be operational in a high degree of certantity on wide variety of hardware, runtime implementation nothing can hold a candle to it.
Erm nope... a modern core can do over 500Mb/sec per core. A gigaBIT NIC only do ~125Mb/sec. So core speed per core speed wins here. Around me it is common for server to have 8 cores and just 2 gigabit NICs. That kind of ratio or better is normal so NICs are your resource restriction.
There is a bottleneck computing the key exchange but then both ends exchange a SSL session id that can be reused for different connections (if both client and server cache and reuse). It can be reused days days/weeks/months later.
The client end has the highest cost CPU overhead of verifying the PKI certificate given out by the server with the local copy of the parent CA installed in the browser. Usually the CA signing key is the largest key in use and the more bits in the PKI key increases the computing power needed to verify it in a non-linear way.
I am sure wikipedia have plenty of scalable HTTPS accelerator hardware endpoints at their disposal to offload all this to.
The topic can also be understood with the flow of electrons through a conductive material. Each atom has electrons spinning around it and a pressure wave is generated at one end causing adjacent atoms to exchange electrons pushes free ones out the other side.
Because it is an exchange of very light particles and not the movement / displacement of atoms that is why electron flows nearer to the speed of light than the speed of sound and also relatively further as the energy loss during each hop is lower.
I'm sure computer chip designers would like to like to keep increasing that clock rate, one factor is the few inches distance between the CPU and other components causes a latency concern to engineer around.
There is a lot of money to take from consumers at the top end.
With the recent announcement of 5/6 GHz CPU being possible and with AMD working on their sequel architecture changes it is important to have a product to put at the top end since holding the crown up there causes a lot more sales across the range.
The same kind of reason why plenty of low end cars are sold by prestigious brands, people like to associate with the brand knowing they make the best (at the top end), easily overlooking the fact they have the budget model and it is not built in anyway the same.
1) Moving the port is worthwhile (don't be the low hanging fruit for bots to take easy shots at). 2) Disable the ability to use "Password Authentication" completly, insist on public/private key system. 3) Use an AllowedUsers list with the minimum usernames in the list (the super user should not be in the list, use 'su/sudo')
I don't know of many scenarios where your point 1 is useful, maybe between an office and some online systems it is possible to lock down to IPs, but then why don't you just setup a VPN network and use that if things will always be fixed/rigid, Having SSH on public facing port maybe because you don't know the IP and/or you need an assured way of getting into an important system from anywhere at anytime with the least number of hoops (i.e. your VPN network might be broken, your fixed IPs might not have internet connectivity, etc..). Your point 2 is valid but standard in many years (6+ on multiple distros I have used), this advice may have been useful when the feature was first created. Point 3 is moot, no one brutes a 2048bit key pair. Point 4 is moot due non use of passwords.
Your ssh keys should have the private keys protected with a local password to armor them from this attack vector.
When you login with an SSH key your local system should prompt you for a password to unlock (decrypt) the private key part. This password never leaves the local device you are using.
This gives you a nice buffer of time between knowing the equipment has been lost and revoking the authorization on the server side. Bruting the local SSH private key password is usually hard work (in CPU time) because the implementors of such systems think more about security than performance. Where as the salted and hashed password of a website system usuauly has performance concerns with having to manage passwords of many users at the same time.
IMHO All login systems of remote systems should take this approach.
So no it doesn't have to succeed first try if you set it up correctly and are not lazy about protecting the private key.
Huh port knocking is per tuple (per source IP and port and destination IP and port). You can bang the ports all you want but you need to do it from my source IP and port number at the time I am doing it, in order to interfere with my port knocking session. Good luck with that!
Move your SSH to another port, Disable Password authentication (accept only public key auth) and Restrict the valid usernames to a short list (ensuring to remove root). Even if they do find the open port it, it won't accept a password from them to brute force. Want to brute force a public key. Good luck with that!
Why use SWT at all I found it to be a collection of lowest common denominator APIs. Just use Qt directly in Java via the QtJambi project.
IMHO If the SWT on Qt project should get more traction in the future it is better throught of as being an "SWT compatibility layer (to help migration away from SWT)" since the direct Qt API in Java is so much better and that API already works on the big 3 desktop enviroments (Windows, Unix and MacOSX). So what purpose does SWT continue to serve.
That isn't what "people" are willing to pay. That is the price of the most recent few 1000 shares that were sold extrapolated across the number of shares issued. The tail wagging the dog.
If you want to know what people are willing to pay you need to sell a lot more shares to extrapolate. Then people will start to look at Profit / Earnings ratios and the voting power the public shares have.
But wasn't one of the terms of Qualcomm's license that it and its customers could not sue MM. Once it (Qualcomm) or one of its customer did sue MM then all or some parts of the license became void.
So because Apple have sued MM this action voided the protection they (Apple) had via Qualcomm's licensing.
Yes. To RMS the Copyright laws are the legal tool he can use enforce his view.
If the option came around to remove those laws for everyone on everything I'm sure RMS would jump at that opportunity of seeing the GNU Public License become obsolete.
The main purpose of his use of Copyright law is to ensure that something he shared with others must continue to be shared forever more.
So this statement of not contradictory with his use of Copyright law. Think of Copyright law as being the mutually agreeable and legal framework in which both he and society can make a compromise (in the today) towards the bigger picture in the future.
All human endevour and knowledge that ever existed after the Copyright term and the Patent term have expired just become shared knowledge. He is accepting this as the absolute truth of the matter and applying it to software.
I hope that in 100 years time the knowledge of the computer chip will be as free as the knowledge of the wheel, I would hope that society take choices and action in the today so that kind of tomorrow may exist regardless of those entities that my try to oppress.
In the future there maybe a war on this matter and society will need to make a choice.
Your costs are obviously way more expensive than mine maybe this is beurocracy. But in all commercial projects I have worked on costs have always been a major consideration over the methods being used. The thread did talk of costs for small scale hosting being an issue to do this kind of thing right. It is obviously possible to spend an infinite amount of money on anything so what is more interesting is how little you can spend to achieve how much.
When open source is being used the costs of software/maintenance only needs to be spent by a small part of the community. The rest can get the benefits for just an hours work to install and setup much like CentOS achieves.
I am claiming that for $100 you can have the hardware and software for this box setup and turnkey to use that comodatized most of the features of a $200,000 solution. Maybe you don't agree with this possibility.
Over the TPM just using ARM CPU SoC that supports write once memory so the boot loader is locked with a signed trust chain. Yes this would exclude the Raspberry-pi but the idea of taking the R-pi design and simply asking a manufacturer to not to install firmware in the same way should do the trick. We want the R-pi design, we want to pay $10 more but we want you to do one less thing during manufacture, no brainer for supplier.
Of course any compromise to the system is a problem. However in a previous reply it has already been explained that:
* You might like to consider using a VM based language and signed bytecode on such a system. As well as SElinux and other such OS things, so for the paranoid then lock firewall rules down to a specific process.
* The box with the key might not just reply to every request to retrieve the key in realtime. It might for example require 2 factor authorization to emit the data, such as a pager/sms/call to a human engineer to authorize the system. This would work much like UAC prompt where the engineer would need to know / expect there to be a reload of this key data to be happening. The whole security thing is just layers of protection and hopefully the attacker will set off a tripwire along the way before they manage to get everything in place to compete the compromise.
You are correct that the 2 parts to the salt serve the same purpose. But there isn't much to be gained or lost from using a larger salt (when we're probably talking about going from 64bit to 128bits) if we presume the values are 64bit each. The userId is something the attacker will know so it can't be used as-is directly as that makes it no more secure than having the salt as the first part of the output string stored in the DB (like/etc/passwd and maybe/etc/shadow does on unix).
But the symmetric key is to encrypt the results of the salted hash and serves a different purpose to armour the data the attacker might be able to lift via any mechanism. This is the same principal that GPG/PGP will armor your private key part with encryption.
This ensures that at all times the salted-hash is conveyed around, is backed up, is stored on disk, it is in an encrypted form that and the decryption key is not stored in the same domain. (it is not in the backup data set as data or code, it is not stored as part of the SQL config if you were using SQL server assisted column encrytion). It is not converyed over TCP with SQL client/server communication to perform data UPDATEs or SELECTs.
In all this makes only one place where all the required data is known in plain text form, that is in the web application where the inbound data from the HTTP client was secured with HTTPS, the SQL data secured with a symmetric key (as well as optionally SSL).
So now you are left with the problem of making sure the host has a clean user-space but things like TPM / SElinux and using VM based network accessible applications.
What are you saying the problem with PBKDF2 is ? is it possible to loose bits of information between input and output (like a truncated input). If anything I would think that PBKDF2 would be the best "key stretcher" there is and it already has the notion of number of rounds that you can adjust to suit your performance/security requirements. Your forum might use 64 rounds and you banking application might use 4096 rounds.
If you store the number of rounds used as part of the symmetric encryted result it is actually possible to seamlessly upgrade everyones number of rounds over time as they login and use the service. i.e. you deploy your application in 2008 and you setup for 2000 rounds and this was good. 1 million users signed up and used the service. Now it is 2012 and you change your policy and configure for 4000 rounds. Now as each user logs in it can validate their stored password against the 2000 rounds ok, but then because it has the password it can upgrade it to the 4000 round versions and overwrite the data in SQL. Any accounts not signed in for 6 months would be auto-locked.
PBKDF2 can also be setup to use whichever hash and HMAC you prefer so again this can be upgradeded in the same way so you deploy in 2008 with SHA1 and in 2012 you choose SHA256.
Personally I think that one of the web browser initiaves for always storing your password credentials locally at the client and having a mechanism that HTTP form login can make use of to login is better. This should be PKI based so there is no authentication data of value to be compromised at the 1000s of website you signup to. It is much better for both user and website operator to put the onus back onto the client to keeping their credentials secure.
No the respberry-pi device is the 3rd server that provides the hardware secured device to contain the secrets.
This device:
* Might only have a console for maintenance (you needed physical access to create/overwrite secrets).
* Would lock down clients using SSL/TLS peer certificate authentication as well as IP based access control. So only the correct IP can ask for the data and that correct IP must have a valid private PKI exchange to validate itself as genuine.
* Might not hand out the data immediately when asked, it might for example open a dialog to a system administrators mobile phone which acts as an alert that require acknowledgement before the secrets are handed to any system.
* Raspberry-pi might support TPM so might have signed boot loader, signed kernel, signed userspace, making the hardware it more tamper proof. A seemingly easier thing to do on an embedded device.
* The device might run linux and all of 2 other processes with no normal userspace again making it difficult to exploit.
* The device would internally log things.
Contrast this with a notion of a 2nd full SQL system that gets rather expensive to maintain compared to a 30 EUR R-pi box.
Slashdot Mirror
DTMF activated question and answer phone message. i.e. you record a message "Please dial the answer to this maths question to be connected; what is 25 + 17 ? Dial this into the phone now." You setup a simple pin that then actually starts the ringer on the phone when entered.
With a phone address book that will bypass this for known callers and numbers (and maybe recent callers that passed). Not really innovative but effective enough. Solution should be simple/cheap/one-chip-digital.
You can then extend this to have the phone dial back a configured number (free phone, 800 number) with the DTMF of 1 in 100 numbers that call you and fail the test.
Of course this shifts the problem to simply pay more money for cheap labor answering challenge questions but the only way to defeat this use of the telephone network is to make it economically nonviable.
This same problem domain as SPAM email, we only needs to make every sender incur a cost to send and CPU power can be that cost, just implement hashcash inside SMTP protocol and the receiver gets to decide how hard (computationally) the problem is, allow the client/sever to exchange cookies to setup good will and reputation over time with many transactions. SPAM problem solved. Now we just need a compute mathematical algorithm that works where one end can create a maths computation problem and compute the solution (by knowing all the data) in very short amount of time, but then hand the problem to the other end to solve (by removing some information) and make is scalable exponentially and iteratively to it keeps working a CPU power gets better. Sure botnets can give them this CPU resource but now the infected user will notice when their CPU is being maxed out and probably get it cleaned sooner!
I think he is saying ... HTC has been a succesful company over these past 6 years and they will also be producing handsets for lower cost and just as high quality as Nokia's handsets are expected to be. Yet HTC has not put all their eggs in one basket but is still able to perform better as a business (i.e. maintain sales and see growth).
It is true that Samsung is trouncing over HTC in the very short term right now but I do not expect this position to stay as-is, HTC will fight back after working out what the problems. Especially when they broaden their available OS on handsets through WP. Maybe Samsung is getting better marketing right now especially in light of Apple's actions, any publicity is good publicity right!
The thing is I can not see Nokia making a useful recovery many "business" people prefer their iDevices now they have already become entrenched in business now. The Microsoft and Nokia partnership looks perfect on paper for this market sector but I think they have been too slow to capture it. The only hope is in these users become disillusioned with their iDevices and wanting to try something different, but I suspect many of them will go back to iDevice right after as WP8 won't actually be that great and their children won't think it is cool enough phone.
I can not at all say (in my opinion) that Nokia has been a sucessful company these past 6 years, I can't find a measure by which to make such a claim. I've purchased Nokia's year after year since 2000 but the E6-00 is likely to be my last. I own an N900 and would have been an owner an N950 or N9 if they had only released it via offical support with warranty channels in my country, not grey import only (9110, 9210, 3210, 6230, 6630, E71, E72, N900, E6-00) to name the models I remember owning. Farewell Nokia I'm happy to let other people be "first movers" on your new platform and tell us all how great it is, but it is going to take a couple of generations of handset and good reviews for me to consider it seriously. After looking a Win8 on desktop I think you have much work to do yet.
But the examples are not equivalent.
You are searching and removing. The snippet Linus quoted is only removing. It is common to already have a pointer to the entry being removed. To suggest we have to walk the list again would pollute cache with all the extra memory being loaded just to save a branch (for any list with more than 3 items I'll have the branch thanks!).
And if you walking the list anyway, the branch 'if(prev)' cited in the supposid 'bad example' is not necessary as it is relevant only for the first iteration of the loop over a single linked list. So you'd test the special first entry case (for 'list_head') and then have a loop that is branch free.
I can only think that Linus did not explain the point well enough to warrant such a detailed cross examination we are making here.
You mean 'converted to GPL' only on a re-release and redistribute ?
This presumes the user has access to the source code of the LGPL work in the first place. The user can not convert to GPL if they don't have the source code of the LGPL work, since thy could never honour their own obligations. A LGPL user can not demand source code from the redistribution point they received a binary works.
Why not NDIVIA just wrapper the API symbols in new NVIDIA Copyrighted code that is also GPL and re-export new symbol names.
This extra "shim" module is now free for use by the NVIDIA blob the link against since it is both compliant with GPL and since they are the Copyrights holder they can provide special license back to themselves for their binary blob.
I find it funny that symbols can have licenses on them, in that all NVIDIA needs to do provide a crappy implementation of the same API mechanics to prove to a court the use of the API symbols is not tied to a single implementation of those symbols. Since you can now theoretically interchange between two competing implementations, the GPL one included in mainline kernel and the proof-of-concept one NVIDIA created for the court of law.
How you secure your keyring is upto you.
Most users will like the convienence of a single password model, but this time that password never leaves the device you are using. Still at risk to keyloggers just like before.
You could if you wanted secure your own secret keyring using a mixture of methods, such as a combined smartcard, password and biometrics. The biometric code unlocks data on a smartcard, the smartcard provides part of the data to the browser and the password entered into the computer completes all the necessary information needed to gain access to the keyring (that maybe stored on smartcard or on computers).
But the point is you get to decide how secure you want to make your keyring, you no longer have to hope the website you are using is understands how to do things securely. Also each website by default will have their own unique key and it is infeasable to brutre force the authentication.
....to populate the place, and it is now only reaching its limits.
This is good news for "mankind" there be plenty of life left in her yet.
Well you should be using port 587 (with or without SSL via STARTTLS command). Maybe one day they will also block port 465 (for the same reasons as port 25). But I can't see them ever blocking 587 as one of the expectations of that port is that you must authenticate to send anything. I've seen some mobile devices default to port 587 already.
Running a mail transport agent (i.e. a system that routes email like Sendmail or MS Exchange) on the end of a charagble per Mb network is a bad idea of everyone.
The sender might incur high costs to themselves when they get their recent outbreak of malware on their portable device.
The receiving email systems have no way to correctly identify the sender is genuine (i.e. not a spammer) or build a rapport with them. This is because mobile use of Internet is usually a via a one-way NAT from a dynamic/random IP. There are also no identying marks to relate one client to another. So in short you are a bad sender of email to a 3rd party that is looking to reduce their risk of SPAM.
While I don't like the idea of such blocking. I can understand the reasons for it. It is best you send all your emails from the mobile device via a system with a static IP and an accountable systems administrator. That could be orange's mail service but it can also be a 3rd part SMTP service using STARTTLS on port 587 Orange won't stop you.
The project you cites have zero downloads (this week). Come back when you've fixed all the bugs and the rest of the world is onboard.
Until then I'll keep using Java as I don't seem to run into the same difficulties you seem to have.
I'm sure realtime does matter but I can stil code in C/C++ for that and the resulting work can still run inside the Java VM in complete harmony. I'm sure you will find it hard to find people suggesting you write your video codecs in Java.
For the bigger picture where a collective project can consist of over 1000 modules with over 200 teams all able to collaborate, inspect, review/debug and see-inside each others modules and then on release day have it deploy and be operational in a high degree of certantity on wide variety of hardware, runtime implementation nothing can hold a candle to it.
QtJambi http://qt-jambi.org/ project exists and allows the best of both world. The Qt API for Java.
to include major revertions.
Ah well long live the GNOME!
Erm nope... a modern core can do over 500Mb/sec per core. A gigaBIT NIC only do ~125Mb/sec. So core speed per core speed wins here. Around me it is common for server to have 8 cores and just 2 gigabit NICs. That kind of ratio or better is normal so NICs are your resource restriction.
There is a bottleneck computing the key exchange but then both ends exchange a SSL session id that can be reused for different connections (if both client and server cache and reuse). It can be reused days days/weeks/months later.
The client end has the highest cost CPU overhead of verifying the PKI certificate given out by the server with the local copy of the parent CA installed in the browser. Usually the CA signing key is the largest key in use and the more bits in the PKI key increases the computing power needed to verify it in a non-linear way.
I am sure wikipedia have plenty of scalable HTTPS accelerator hardware endpoints at their disposal to offload all this to.
The topic can also be understood with the flow of electrons through a conductive material. Each atom has electrons spinning around it and a pressure wave is generated at one end causing adjacent atoms to exchange electrons pushes free ones out the other side.
Because it is an exchange of very light particles and not the movement / displacement of atoms that is why electron flows nearer to the speed of light than the speed of sound and also relatively further as the energy loss during each hop is lower.
I'm sure computer chip designers would like to like to keep increasing that clock rate, one factor is the few inches distance between the CPU and other components causes a latency concern to engineer around.
There is a lot of money to take from consumers at the top end.
With the recent announcement of 5/6 GHz CPU being possible and with AMD working on their sequel architecture changes it is important to have a product to put at the top end since holding the crown up there causes a lot more sales across the range.
The same kind of reason why plenty of low end cars are sold by prestigious brands, people like to associate with the brand knowing they make the best (at the top end), easily overlooking the fact they have the budget model and it is not built in anyway the same.
From what I understand of the situation Java6 is not affected (only changes made for Java 7).
Yes you apple users should seriously make a stand on that forced upgrade or no support for you policy.
I think you failed at the important matters:
1) Moving the port is worthwhile (don't be the low hanging fruit for bots to take easy shots at).
2) Disable the ability to use "Password Authentication" completly, insist on public/private key system.
3) Use an AllowedUsers list with the minimum usernames in the list (the super user should not be in the list, use 'su/sudo')
I don't know of many scenarios where your point 1 is useful, maybe between an office and some online systems it is possible to lock down to IPs, but then why don't you just setup a VPN network and use that if things will always be fixed/rigid, Having SSH on public facing port maybe because you don't know the IP and/or you need an assured way of getting into an important system from anywhere at anytime with the least number of hoops (i.e. your VPN network might be broken, your fixed IPs might not have internet connectivity, etc..).
Your point 2 is valid but standard in many years (6+ on multiple distros I have used), this advice may have been useful when the feature was first created.
Point 3 is moot, no one brutes a 2048bit key pair.
Point 4 is moot due non use of passwords.
Your ssh keys should have the private keys protected with a local password to armor them from this attack vector.
When you login with an SSH key your local system should prompt you for a password to unlock (decrypt) the private key part. This password never leaves the local device you are using.
This gives you a nice buffer of time between knowing the equipment has been lost and revoking the authorization on the server side. Bruting the local SSH private key password is usually hard work (in CPU time) because the implementors of such systems think more about security than performance. Where as the salted and hashed password of a website system usuauly has performance concerns with having to manage passwords of many users at the same time.
IMHO All login systems of remote systems should take this approach.
So no it doesn't have to succeed first try if you set it up correctly and are not lazy about protecting the private key.
Huh port knocking is per tuple (per source IP and port and destination IP and port). You can bang the ports all you want but you need to do it from my source IP and port number at the time I am doing it, in order to interfere with my port knocking session. Good luck with that!
Move your SSH to another port, Disable Password authentication (accept only public key auth) and Restrict the valid usernames to a short list (ensuring to remove root). Even if they do find the open port it, it won't accept a password from them to brute force. Want to brute force a public key. Good luck with that!
Why use SWT at all I found it to be a collection of lowest common denominator APIs. Just use Qt directly in Java via the QtJambi project.
IMHO If the SWT on Qt project should get more traction in the future it is better throught of as being an "SWT compatibility layer (to help migration away from SWT)" since the direct Qt API in Java is so much better and that API already works on the big 3 desktop enviroments (Windows, Unix and MacOSX). So what purpose does SWT continue to serve.
That isn't what "people" are willing to pay. That is the price of the most recent few 1000 shares that were sold extrapolated across the number of shares issued. The tail wagging the dog.
If you want to know what people are willing to pay you need to sell a lot more shares to extrapolate. Then people will start to look at Profit / Earnings ratios and the voting power the public shares have.
But wasn't one of the terms of Qualcomm's license that it and its customers could not sue MM. Once it (Qualcomm) or one of its customer did sue MM then all or some parts of the license became void.
So because Apple have sued MM this action voided the protection they (Apple) had via Qualcomm's licensing.
Yes. To RMS the Copyright laws are the legal tool he can use enforce his view.
If the option came around to remove those laws for everyone on everything I'm sure RMS would jump at that opportunity of seeing the GNU Public License become obsolete.
The main purpose of his use of Copyright law is to ensure that something he shared with others must continue to be shared forever more.
So this statement of not contradictory with his use of Copyright law. Think of Copyright law as being the mutually agreeable and legal framework in which both he and society can make a compromise (in the today) towards the bigger picture in the future.
All human endevour and knowledge that ever existed after the Copyright term and the Patent term have expired just become shared knowledge. He is accepting this as the absolute truth of the matter and applying it to software.
I hope that in 100 years time the knowledge of the computer chip will be as free as the knowledge of the wheel, I would hope that society take choices and action in the today so that kind of tomorrow may exist regardless of those entities that my try to oppress.
In the future there maybe a war on this matter and society will need to make a choice.
Your costs are obviously way more expensive than mine maybe this is beurocracy. But in all commercial projects I have worked on costs have always been a major consideration over the methods being used. The thread did talk of costs for small scale hosting being an issue to do this kind of thing right. It is obviously possible to spend an infinite amount of money on anything so what is more interesting is how little you can spend to achieve how much.
When open source is being used the costs of software/maintenance only needs to be spent by a small part of the community. The rest can get the benefits for just an hours work to install and setup much like CentOS achieves.
I am claiming that for $100 you can have the hardware and software for this box setup and turnkey to use that comodatized most of the features of a $200,000 solution. Maybe you don't agree with this possibility.
Over the TPM just using ARM CPU SoC that supports write once memory so the boot loader is locked with a signed trust chain. Yes this would exclude the Raspberry-pi but the idea of taking the R-pi design and simply asking a manufacturer to not to install firmware in the same way should do the trick. We want the R-pi design, we want to pay $10 more but we want you to do one less thing during manufacture, no brainer for supplier.
Of course any compromise to the system is a problem. However in a previous reply it has already been explained that:
* You might like to consider using a VM based language and signed bytecode on such a system. As well as SElinux and other such OS things, so for the paranoid then lock firewall rules down to a specific process.
* The box with the key might not just reply to every request to retrieve the key in realtime. It might for example require 2 factor authorization to emit the data, such as a pager/sms/call to a human engineer to authorize the system. This would work much like UAC prompt where the engineer would need to know / expect there to be a reload of this key data to be happening.
The whole security thing is just layers of protection and hopefully the attacker will set off a tripwire along the way before they manage to get everything in place to compete the compromise.
You are correct that the 2 parts to the salt serve the same purpose. But there isn't much to be gained or lost from using a larger salt (when we're probably talking about going from 64bit to 128bits) if we presume the values are 64bit each. The userId is something the attacker will know so it can't be used as-is directly as that makes it no more secure than having the salt as the first part of the output string stored in the DB (like /etc/passwd and maybe /etc/shadow does on unix).
But the symmetric key is to encrypt the results of the salted hash and serves a different purpose to armour the data the attacker might be able to lift via any mechanism. This is the same principal that GPG/PGP will armor your private key part with encryption.
This ensures that at all times the salted-hash is conveyed around, is backed up, is stored on disk, it is in an encrypted form that and the decryption key is not stored in the same domain. (it is not in the backup data set as data or code, it is not stored as part of the SQL config if you were using SQL server assisted column encrytion). It is not converyed over TCP with SQL client/server communication to perform data UPDATEs or SELECTs.
In all this makes only one place where all the required data is known in plain text form, that is in the web application where the inbound data from the HTTP client was secured with HTTPS, the SQL data secured with a symmetric key (as well as optionally SSL).
So now you are left with the problem of making sure the host has a clean user-space but things like TPM / SElinux and using VM based network accessible applications.
What are you saying the problem with PBKDF2 is ? is it possible to loose bits of information between input and output (like a truncated input). If anything I would think that PBKDF2 would be the best "key stretcher" there is and it already has the notion of number of rounds that you can adjust to suit your performance/security requirements. Your forum might use 64 rounds and you banking application might use 4096 rounds.
If you store the number of rounds used as part of the symmetric encryted result it is actually possible to seamlessly upgrade everyones number of rounds over time as they login and use the service. i.e. you deploy your application in 2008 and you setup for 2000 rounds and this was good. 1 million users signed up and used the service. Now it is 2012 and you change your policy and configure for 4000 rounds. Now as each user logs in it can validate their stored password against the 2000 rounds ok, but then because it has the password it can upgrade it to the 4000 round versions and overwrite the data in SQL. Any accounts not signed in for 6 months would be auto-locked.
PBKDF2 can also be setup to use whichever hash and HMAC you prefer so again this can be upgradeded in the same way so you deploy in 2008 with SHA1 and in 2012 you choose SHA256.
Personally I think that one of the web browser initiaves for always storing your password credentials locally at the client and having a mechanism that HTTP form login can make use of to login is better. This should be PKI based so there is no authentication data of value to be compromised at the 1000s of website you signup to. It is much better for both user and website operator to put the onus back onto the client to keeping their credentials secure.
No the respberry-pi device is the 3rd server that provides the hardware secured device to contain the secrets.
This device:
* Might only have a console for maintenance (you needed physical access to create/overwrite secrets).
* Would lock down clients using SSL/TLS peer certificate authentication as well as IP based access control. So only the correct IP can ask for the data and that correct IP must have a valid private PKI exchange to validate itself as genuine.
* Might not hand out the data immediately when asked, it might for example open a dialog to a system administrators mobile phone which acts as an alert that require acknowledgement before the secrets are handed to any system.
* Raspberry-pi might support TPM so might have signed boot loader, signed kernel, signed userspace, making the hardware it more tamper proof. A seemingly easier thing to do on an embedded device.
* The device might run linux and all of 2 other processes with no normal userspace again making it difficult to exploit.
* The device would internally log things.
Contrast this with a notion of a 2nd full SQL system that gets rather expensive to maintain compared to a 30 EUR R-pi box.