I've wondered why passwords are used. With the tech we have (including a way to ensure the clock is set correctly via NTP), why not use both a service password and a OTP using a TOTP mechanism like the Google Authenticator? Done right with the key inputted to a device [1] handed to the service person, they wouldn't be able to extract the TOTP seed, which would prevent someone selling the password.
Or, perhaps add a smartcard to the mix. The US government uses PIV/CACs all the time, why not use that tech in an ATM?
[1]: This device could even be an iPod Touch. I keep one of these around just for the sole purpose of working with Duo and Authy, just in case I lose my phone. It wouldn't be too difficult for a bank to make a dedicated device that would lock itself if taken outside a geofenced area.
Similar here. I'm proud of what I have done with my coding, as it solved a problem and fills a need.
Now, coding style and such... I wind up refactoring everything so it is more readable, files are replaced with constants rather than hard coded, adding some error checking, adding "set -euo pipefile" if in bash, etc. Since scripting is a one-off item, the sooner I can put things like that in a manifest, recipe, or playbook, the better.
Synology and QNAP NAS products offer Time Machine compatibility. It isn't tough to set up (make a directory, share it), but it is an acceptable replacement for a Time Capsule. As an added bonus, you can have units that have RAID protection, and be able to take the TM stash and snapshot/back that up to a separate place (although you are backing up a backup.)
Then the device gets compromised, tells the firewall to do allow everything as the manifest, and the fun begins. It might be that the device presents a signed (and a CA system is a solved problem similar to signed executables) manifest, allowing the device access, but if the signature chain isn't valid, it would be ignored.
Of course, this causes the issue of who controls the CA chain to rear its ugly head, because who becomes the root CA now has the keys to the kingdom that all the IoT makers must defer to. However, it can be argued that this is better than nothing.
If the maker puts in an IP address or DNS host, they are responsible for it, so it would be about the same risk as a company ninja-flashing an Android phone to double as a USB zapper. A manifest would make it at least known that the maker did vouch for the IP address.
There are many issues with this manifest system, be it who validates signatures, how do the firewalls grab devices, how are manifests updated and how is a firewall admin presented with updates. However, this is far better than nothing, as as of now, nothing is exactly what IoT security is.
Ideally, there should be a profile/manifest IoT makers have as standard with their devices. This shows what incoming/outgoing ports and hosts the IoT device communicates with. Everything else should be blocked as default from the router. This should be in some central registry or a standardized URL system, so a home firewall could, once it recognizes a certain IoT device, grab a profile and run with it.
Of course, a lot of IoT makers would just put in that the device takes incoming/outgoing traffic from anything and everything, but hopefully there might be come makers who give a shit enough about security to put in limits of what their devices can and do not try communicating with.
This way, a firewall, once it registers a device can automatically apply a profile and call it done. Of course, there are security issues, but this is a giant step forward, compared to letting the device have unfettered access in and out.
I used to do that, but I prefer browsing in VMs, just so if something escapes one browser, it can't do much, and a snapshot rollback instantly fixes all damage.
Browser-wise, I would give Chrome the nod (although it doesn't have NoScript-like functionality) because of how it runs Flash and other items in separate VMs, limiting the context a compromised add-on can damage. Add uBlock Origin and Tampermonkey, and this does an adequate job at dealing with malvertising.
In my experience, blocking ads does a lot more for security than almost any AV utility. AV utilities are stymied by 0-days. Ad blockers don't care how old the exploit is... if it can't load through an ad server, it doesn't run.
The ironic thing is that it is definitely in their interest. If they hose things and satellites start getting destroyed with debris going everywhere in that orbit, Kessler Syndrome will be definitely a show-stopper and not just shut SpaceX down, but pretty much endeavor that goes past the atmosphere. This is already happening, with the ISS already having a solar panel get perforated by debris, and occasionally having to do maneuvers to avoid larger items.
Unless someone has a magic cure for getting space debris to just give up and fall into the atmosphere, fuck-ups by any satellite maker can affect every single space venture there is to the point where launching anything into space becomes an impossibility.
I'd rather have a MacBook Pro as thick as my 2008 aluminum MB, especially if I could get things like replaceable RAM, SSD, and a removable battery. If I want thin above all else, that's what MacBooks are for.
Barring that, maybe Apple should look at the design of their old PowerBook Duo. A thin laptop, but stick it in a docking station, and you gain a lot more ports. Done right, this could be a decent compromise between a thin laptop and a decent desktop with good performance, especially if it has the ability to have a decent GPU in the dock, additional SSDs/HDDs, and multiple 10gigE NICs. Having a dock with "all the ports" would be useful as well.
Very true, they don't have a responsibility to police users, but if their IP range starts getting known for malware, it is likely that IP range will wind up on blackhole lists, and that is a black eye for the cloud provider when clients start complaining they can't reach other businesses.
I wished Apple would have a special connector that routed USB-C through MagSafe, so the MagSafe connector could do power and data. That way, with one plug, I could have it attached to a port replicator, and with enough PCI lines, have decent video, perhaps a real GPU, etc.
The bootloaders should be like Google Nexus or Pixel devices. Ship locked, but with a preference setting and a fastboot command, can be unlocked by a clued user. This way, I can install a ROM, relock the bootloader. If a bad guy steals my phone and unlocks the bootloader to try to bypass the ROM, the phone will have cleaned off the/data partition and reset.
Removable batteries are a nice thing. Beats bulky battery cases.
SD-Card slots are useful. Two would be nice, one for bolstering internal storage, and another SD card as a place for Titanium Backup to dump backups.
As for Knox E-fuses, there is a place for that, but they need to be resettable by the end user. It is the end user's phone, after all.
I also like the fact that mSecure doesn't have to have its own website for syncing one's devices. LastPass gets me a tad leery with some of the features, be it allowing someone to access your password stash, easy password resets, and other items. If LP can reset my password via 2FA, then a bad guy can do the same. With mSecure, if I lose my sync password or endpoint passwords, there is no recovering the data other than brute force, and that's how I prefer it.
I would say pretty much the same thing. Depending on threat, use a VPN, an offshore VPN, or TOR.
Worries about access is fairly easy to deal with evercookies. Have a VM and use vagrant to kick it up, provision it with a web browser, ad blocking extensions and such. When done with that session, do a vagrant destroy.
That is a good thing, which is why I mentioned that the plug type is as it is... because both sides do a handshake first before power is turned on. Otherwise someone would stick some bolts in the holes, get shocked, then go sue for a lot of cash. The J1772 design is pretty cool, where a relay flips power off before the plug is completely removed, which saves the physical connectors from pitting due to arcing.
I wonder if part of the reason for the fugly plugs is that the makers don't want to get sued if someone tries to wire 440VAC across their nipples or someone sticks a wire clothes hanger and tries to short circuit things.
This is what a lead-acid core charge is for... to encourage people to get batteries back to a recycler, and perhaps to cover the aspect of breaking up the batteries, neutralizing the acid, dumping all the lead into a smelter to purify and recast, then make new batteries. Other than the plastic casing, batteries are pretty well recyclable, provided they arrive to the recycle place intact.
Oddly enough, this topic goes back and forth on RV forums. Say someone needs 200 ampere-hours for a weekend. They can either buy two lead-acid batteries (each being about a C-note), or go LiFePO4, which can go up to 20x the price. Most people just stay with the lead-acid ones. However, it seems that more people are moving to LiFePO4 batteries because of the higher energy density, and the fact that you can draw them to almost empty without damaging them, even though they have a huge price premium.
NiFe batteries definitely have a place. Iron Edison batteries are used in stationary solar arrays because they are easy to take care of (built in watering system), and can handle a lot of cycles. Long life is crucial in this application. NiFe batteries also don't get damaged when their charge level is below 50%.
However, NiFe batteries have a relatively low energy per volume density compared to lead-acid or lithium batteries. You wouldn't want to use NiFe batteries as electrical storage in your campervan, for example.
Supercaps have their place. Even though they have a lot less energy density than batteries, they are useful to have with a solar array just because they can be charged up quickly, with less need of a precise charge controller with scaling voltages to SoC levels (especially lithium batteries that will go boom if they are not precisely charged/discharged). Supercaps can allow charging to continue for batteries for a little bit after the sun goes down as well as help maintain an even charge if a cloud passes over the panels.
It would be nice to see some advance to allow supercaps to have a better energy density per volume. The fact that they have a virtually unlimited charge/discharge life (as the charging is a physical, not chemical process) and they can handle a lot of incoming amperage is quite nice.
If I need one password, I'd like to use some form of 2FA with it, be it a key residing on a device + a PIN, a password + keyfile, or similar. Something to ward off a brute force attack.
I do this with my TrueCrypt/VeraCrypt volumes when storing those offsite. They get encrypted with a password and a keyfile, with the keyfile stashed in a secure location. This way, if the offsite account is compromised, an attacker has to deal with the entire 256-bit keyspace, as brute-forcing passwords is not an option.
As a compromise, I have started using an app (mSecure) that offers a different encryption key for what is syncs with Dropbox or iClouyd, as it does for the local device. The nice thing about this is that one can use a very long password (32+ characters) for the file that is stashed on the cloud, while having a much shorter key for the app that is sitting on an already encrypted device.
I don't trust a service that is dedicated to storing passwords. It is an obvious target. Yes, one has an encryption password, but those tend to be relatively short so one can access it on a device without taking too much time. Even if their system is secure, how can one be assured that they don't push out an update that might save the decryption password somewhere else. In a two tier system where the password manager rides atop a cloud provider, it would require an attacker to compromise both the cloud provider account and the password manager in order to get access.
Ideally, the password manager of choice would be one that would have all endpoints use RSA keys. When adding a new device for access to the password database, its key would be "introduced" by an existing device, and the master decryption key encrypted by the device's public key. For a general purpose Web browser, JavaScript and HTML5 support key generation and use, so for that browser session, a temporary key can be used and "introduced" by another device, perhaps stored locally, or if the user is using a client cert, use that as a means of decryption somehow. Just for recovery's sake, if the user wanted, they could input (or have generated for them) a long recovery string. This can even be done with existing formats. The OpenPGP file format can easily handle multiple keys, be it public keys or symmetric passphrases.
This way, the password database stored on the cloud provider has no password to be easily brute forced.
I would say solar panels are hit and miss. For a relative's house that has the most roof surface north facing with a lot of trees, the usefulness is there, but limited. However, for a friend of mine on his farm with half his roof facing south, not to mention a pole barn, there is enough square footage that even with a penalty of wattage over solar panels, it will still bring in a lot of amperage. The storage batteries are especially nice because that pretty much gives one a whole-house UPS.
Solar has gotten cheaper all around, but the only two places where I wish improvements could be made would be in the MPPT charger department (PWM chargers are dirt cheap, but you lose a good chunk of wattage), and (as everyone else wishes), the battery department. Get batteries even an order of magnitude near the energy density per volume of gasoline, and that would revolutionize almost everything, especially transportation related.
Slashdot Mirror
I've wondered why passwords are used. With the tech we have (including a way to ensure the clock is set correctly via NTP), why not use both a service password and a OTP using a TOTP mechanism like the Google Authenticator? Done right with the key inputted to a device [1] handed to the service person, they wouldn't be able to extract the TOTP seed, which would prevent someone selling the password.
Or, perhaps add a smartcard to the mix. The US government uses PIV/CACs all the time, why not use that tech in an ATM?
[1]: This device could even be an iPod Touch. I keep one of these around just for the sole purpose of working with Duo and Authy, just in case I lose my phone. It wouldn't be too difficult for a bank to make a dedicated device that would lock itself if taken outside a geofenced area.
Similar here. I'm proud of what I have done with my coding, as it solved a problem and fills a need.
Now, coding style and such... I wind up refactoring everything so it is more readable, files are replaced with constants rather than hard coded, adding some error checking, adding "set -euo pipefile" if in bash, etc. Since scripting is a one-off item, the sooner I can put things like that in a manifest, recipe, or playbook, the better.
Synology and QNAP NAS products offer Time Machine compatibility. It isn't tough to set up (make a directory, share it), but it is an acceptable replacement for a Time Capsule. As an added bonus, you can have units that have RAID protection, and be able to take the TM stash and snapshot/back that up to a separate place (although you are backing up a backup.)
Then the device gets compromised, tells the firewall to do allow everything as the manifest, and the fun begins. It might be that the device presents a signed (and a CA system is a solved problem similar to signed executables) manifest, allowing the device access, but if the signature chain isn't valid, it would be ignored.
Of course, this causes the issue of who controls the CA chain to rear its ugly head, because who becomes the root CA now has the keys to the kingdom that all the IoT makers must defer to. However, it can be argued that this is better than nothing.
If the maker puts in an IP address or DNS host, they are responsible for it, so it would be about the same risk as a company ninja-flashing an Android phone to double as a USB zapper. A manifest would make it at least known that the maker did vouch for the IP address.
There are many issues with this manifest system, be it who validates signatures, how do the firewalls grab devices, how are manifests updated and how is a firewall admin presented with updates. However, this is far better than nothing, as as of now, nothing is exactly what IoT security is.
Ideally, there should be a profile/manifest IoT makers have as standard with their devices. This shows what incoming/outgoing ports and hosts the IoT device communicates with. Everything else should be blocked as default from the router. This should be in some central registry or a standardized URL system, so a home firewall could, once it recognizes a certain IoT device, grab a profile and run with it.
Of course, a lot of IoT makers would just put in that the device takes incoming/outgoing traffic from anything and everything, but hopefully there might be come makers who give a shit enough about security to put in limits of what their devices can and do not try communicating with.
This way, a firewall, once it registers a device can automatically apply a profile and call it done. Of course, there are security issues, but this is a giant step forward, compared to letting the device have unfettered access in and out.
I used to do that, but I prefer browsing in VMs, just so if something escapes one browser, it can't do much, and a snapshot rollback instantly fixes all damage.
Browser-wise, I would give Chrome the nod (although it doesn't have NoScript-like functionality) because of how it runs Flash and other items in separate VMs, limiting the context a compromised add-on can damage. Add uBlock Origin and Tampermonkey, and this does an adequate job at dealing with malvertising.
In my experience, blocking ads does a lot more for security than almost any AV utility. AV utilities are stymied by 0-days. Ad blockers don't care how old the exploit is... if it can't load through an ad server, it doesn't run.
Or a master server...
The ironic thing is that it is definitely in their interest. If they hose things and satellites start getting destroyed with debris going everywhere in that orbit, Kessler Syndrome will be definitely a show-stopper and not just shut SpaceX down, but pretty much endeavor that goes past the atmosphere. This is already happening, with the ISS already having a solar panel get perforated by debris, and occasionally having to do maneuvers to avoid larger items.
Unless someone has a magic cure for getting space debris to just give up and fall into the atmosphere, fuck-ups by any satellite maker can affect every single space venture there is to the point where launching anything into space becomes an impossibility.
I'd rather have a MacBook Pro as thick as my 2008 aluminum MB, especially if I could get things like replaceable RAM, SSD, and a removable battery. If I want thin above all else, that's what MacBooks are for.
Barring that, maybe Apple should look at the design of their old PowerBook Duo. A thin laptop, but stick it in a docking station, and you gain a lot more ports. Done right, this could be a decent compromise between a thin laptop and a decent desktop with good performance, especially if it has the ability to have a decent GPU in the dock, additional SSDs/HDDs, and multiple 10gigE NICs. Having a dock with "all the ports" would be useful as well.
Very true, they don't have a responsibility to police users, but if their IP range starts getting known for malware, it is likely that IP range will wind up on blackhole lists, and that is a black eye for the cloud provider when clients start complaining they can't reach other businesses.
I wished Apple would have a special connector that routed USB-C through MagSafe, so the MagSafe connector could do power and data. That way, with one plug, I could have it attached to a port replicator, and with enough PCI lines, have decent video, perhaps a real GPU, etc.
The hot air helps with aerodynamics.
The bootloaders should be like Google Nexus or Pixel devices. Ship locked, but with a preference setting and a fastboot command, can be unlocked by a clued user. This way, I can install a ROM, relock the bootloader. If a bad guy steals my phone and unlocks the bootloader to try to bypass the ROM, the phone will have cleaned off the /data partition and reset.
Removable batteries are a nice thing. Beats bulky battery cases.
SD-Card slots are useful. Two would be nice, one for bolstering internal storage, and another SD card as a place for Titanium Backup to dump backups.
As for Knox E-fuses, there is a place for that, but they need to be resettable by the end user. It is the end user's phone, after all.
I also like the fact that mSecure doesn't have to have its own website for syncing one's devices. LastPass gets me a tad leery with some of the features, be it allowing someone to access your password stash, easy password resets, and other items. If LP can reset my password via 2FA, then a bad guy can do the same. With mSecure, if I lose my sync password or endpoint passwords, there is no recovering the data other than brute force, and that's how I prefer it.
I would say pretty much the same thing. Depending on threat, use a VPN, an offshore VPN, or TOR.
Worries about access is fairly easy to deal with evercookies. Have a VM and use vagrant to kick it up, provision it with a web browser, ad blocking extensions and such. When done with that session, do a vagrant destroy.
That is a good thing, which is why I mentioned that the plug type is as it is... because both sides do a handshake first before power is turned on. Otherwise someone would stick some bolts in the holes, get shocked, then go sue for a lot of cash. The J1772 design is pretty cool, where a relay flips power off before the plug is completely removed, which saves the physical connectors from pitting due to arcing.
I wonder if part of the reason for the fugly plugs is that the makers don't want to get sued if someone tries to wire 440VAC across their nipples or someone sticks a wire clothes hanger and tries to short circuit things.
This is what a lead-acid core charge is for... to encourage people to get batteries back to a recycler, and perhaps to cover the aspect of breaking up the batteries, neutralizing the acid, dumping all the lead into a smelter to purify and recast, then make new batteries. Other than the plastic casing, batteries are pretty well recyclable, provided they arrive to the recycle place intact.
Oddly enough, this topic goes back and forth on RV forums. Say someone needs 200 ampere-hours for a weekend. They can either buy two lead-acid batteries (each being about a C-note), or go LiFePO4, which can go up to 20x the price. Most people just stay with the lead-acid ones. However, it seems that more people are moving to LiFePO4 batteries because of the higher energy density, and the fact that you can draw them to almost empty without damaging them, even though they have a huge price premium.
NiFe batteries definitely have a place. Iron Edison batteries are used in stationary solar arrays because they are easy to take care of (built in watering system), and can handle a lot of cycles. Long life is crucial in this application. NiFe batteries also don't get damaged when their charge level is below 50%.
However, NiFe batteries have a relatively low energy per volume density compared to lead-acid or lithium batteries. You wouldn't want to use NiFe batteries as electrical storage in your campervan, for example.
Supercaps have their place. Even though they have a lot less energy density than batteries, they are useful to have with a solar array just because they can be charged up quickly, with less need of a precise charge controller with scaling voltages to SoC levels (especially lithium batteries that will go boom if they are not precisely charged/discharged). Supercaps can allow charging to continue for batteries for a little bit after the sun goes down as well as help maintain an even charge if a cloud passes over the panels.
It would be nice to see some advance to allow supercaps to have a better energy density per volume. The fact that they have a virtually unlimited charge/discharge life (as the charging is a physical, not chemical process) and they can handle a lot of incoming amperage is quite nice.
If I need one password, I'd like to use some form of 2FA with it, be it a key residing on a device + a PIN, a password + keyfile, or similar. Something to ward off a brute force attack.
I do this with my TrueCrypt/VeraCrypt volumes when storing those offsite. They get encrypted with a password and a keyfile, with the keyfile stashed in a secure location. This way, if the offsite account is compromised, an attacker has to deal with the entire 256-bit keyspace, as brute-forcing passwords is not an option.
As a compromise, I have started using an app (mSecure) that offers a different encryption key for what is syncs with Dropbox or iClouyd, as it does for the local device. The nice thing about this is that one can use a very long password (32+ characters) for the file that is stashed on the cloud, while having a much shorter key for the app that is sitting on an already encrypted device.
I don't trust a service that is dedicated to storing passwords. It is an obvious target. Yes, one has an encryption password, but those tend to be relatively short so one can access it on a device without taking too much time. Even if their system is secure, how can one be assured that they don't push out an update that might save the decryption password somewhere else. In a two tier system where the password manager rides atop a cloud provider, it would require an attacker to compromise both the cloud provider account and the password manager in order to get access.
Ideally, the password manager of choice would be one that would have all endpoints use RSA keys. When adding a new device for access to the password database, its key would be "introduced" by an existing device, and the master decryption key encrypted by the device's public key. For a general purpose Web browser, JavaScript and HTML5 support key generation and use, so for that browser session, a temporary key can be used and "introduced" by another device, perhaps stored locally, or if the user is using a client cert, use that as a means of decryption somehow. Just for recovery's sake, if the user wanted, they could input (or have generated for them) a long recovery string. This can even be done with existing formats. The OpenPGP file format can easily handle multiple keys, be it public keys or symmetric passphrases.
This way, the password database stored on the cloud provider has no password to be easily brute forced.
I would say solar panels are hit and miss. For a relative's house that has the most roof surface north facing with a lot of trees, the usefulness is there, but limited. However, for a friend of mine on his farm with half his roof facing south, not to mention a pole barn, there is enough square footage that even with a penalty of wattage over solar panels, it will still bring in a lot of amperage. The storage batteries are especially nice because that pretty much gives one a whole-house UPS.
Solar has gotten cheaper all around, but the only two places where I wish improvements could be made would be in the MPPT charger department (PWM chargers are dirt cheap, but you lose a good chunk of wattage), and (as everyone else wishes), the battery department. Get batteries even an order of magnitude near the energy density per volume of gasoline, and that would revolutionize almost everything, especially transportation related.