Not too shabby
|
| Author | Content |
|---|---|
| dotmatrix Jan 15, 2017 11:17 AM EDT |
However, I would make a few changes to this particular idea.
|
| dotmatrix Jan 15, 2017 11:49 AM EDT |
I created a random 'plasma' image in gimp and uploaded to postimg... and here's a simple script....
mkdir ~/.some
cd ~/.some
wget https://s26.postimg.org/kh6n63t5l/pic1.png
sha256sum pic1.png |rev
cd ~
rm -r ~/.some
|
| jdixon Jan 15, 2017 5:17 PM EDT |
Does anyone have any experience with the cheaper USB fingerprint readers out there? Are any of them any good? |
| gus3 Jan 15, 2017 5:47 PM EDT |
I just want Edna Mode's home security system. Is that too much to ask? |
| relativ6 Jan 15, 2017 8:58 PM EDT |
dotmatrix - I hadn't thought of that. I like the idea of a script and rotating images. Very creative. And wget is a smarter retrieval method of course, I just tried to make it simple. Thanks for reading. Darren Edit: I added your script to my original post. |
| AwesomeTux Jan 16, 2017 7:07 AM EDT |
Don't do this. What happens when Wikimedia Commons decides to delete the image, or resize it, or reformat it to save space, or add or remove EXIF data? Not to mention the fact that SHA-2 hashes are used to ensure a file made it over the internet successfully, meaning by its very nature its possible the file doesn't make it over the internet correctly and you get a different hash. "Save it locally than." What happens when a rogue program decides to mess with the EXIF data, or add rotation information, or data corruption happens? This is a bad idea. Don't do it. It's a fine way to generate a password that you plan to store somewhere, but its not a good way to ensure the password is retrievable or regeneratable. |
| dotmatrix Jan 16, 2017 10:50 AM EDT |
AwesomeTux wrote:This is a bad idea. Don't do it. A password is a password is a password. Of course, there will be many persons up in arms at this statement. But... There are numerous methods and philosophies to obtain some 'perfected' password generation and storage scheme. Not a single one of these methods provides a 'secure' password. The whole password architecture is insecure. To my knowledge, there is currently only one wide spread method of authenticating without a password. That method is x509 client certificate authentication. However, x509 client certs require the web domain to issue client certs to its clients. And the certificate itself is subject to theft from the client computing platform. The OP article presents an OK method of generating a predictable textual password. Of course, there are several various 'attack' vectors. One is, of course, a third party moving/changing/replacing the url file. And another is a malware placed key logger. And another is, with my above posted script, theft of the script. And so on and so forth... The problem solved by choosing a password that is long and of sufficient entropy is protecting the plain text password from attack if the web service's server database is compromised. However, there is at least one very important assumption... that the web service's password database is salting and hashing the passwords. Passwords are insecure. They are not a good authentication method. Passwords are used because they are inexpensive to implement and are convenient for the end user. However, all forms of password implementation are susceptible to theft through locally compromised machines or various other compromises. The above is why passwords need to disappear as an authentication mechanism. They should be replaced by a cryptographically secure architecture. My personal favorite would be a PGP authentication mechanism. If PGP authentication were an Internet standard implementation, the end user could protect all authentication from current 'password-like' vulnerabilities by purchasing an OpenPGP smartcard and generating the crypto keys on the card. The smartcard generated secret keys are not exportable, and so can not be stolen through installation of malware or even through local compromise. The card itself must be stolen. Long story short... The OP article author's idea is a good one, considering the very real problems with all other password generation as well as the problem solved... high entropy and predictability of a password while hiding the hint over the entire web address space. The third party problem goes away if you place files at a location the user controls. The problem of discovery goes away completely if the user runs a personal web server and places the files in a hidden and unsearchable directory on the web server, relying on the "Options -Indexes" to prevent listing of the files. This location could be nearly impossible to locate by chance or brute force if it is a UUID link as well. And if you want to get really, really crazy... you could create a user on the system and an associated ssh public key, and then do the hashing on the server itself... just retrieve the 'current' password via something like: scp -i ~/.ssh/my_ssh_key my_user@my_domain.tld:~/.ho_hum/current And lastly, if you want a crazy easy solution... you could implement a slightly less 'secure' method and enable UserDir on apache and place the generated 'password' on a UUID link within the user's webspace, relying on TLS to protect the 'plaintext' snooping. https://my_domain.tld/~my_user/.1b826ff7-9b31-4539-b411-849b5c13131bOf course... there will be many people complaining and up in arms... but when has that not been true? |
| dotmatrix Jan 16, 2017 10:56 AM EDT |
@relativ6: Just noticed the update... Thanks! |
| AwesomeTux Jan 16, 2017 2:08 PM EDT |
@dotmatrix the issues with this approach aren't about security at all, they're about the ability to actually retrieve the password. The file can be (accidentally) moved or deleted, it can be modified even if only slightly, and it can be silently corrupted. All of these things mean you will get a different hash, meaning you will never know the password again. There's also this: I wrote:SHA-2 hashes are used to ensure a file made it over the internet successfully, meaning by its very nature its possible the file doesn't make it over the internet correctly and you get a different hash. How do you fix this? This one isn't even about what may happen to the file. Just the simple fact that retrieving the file depends on a working internet connection creates all sorts of potential issues. |
| dotmatrix Jan 16, 2017 2:39 PM EDT |
>The file can be (accidentally) moved or deleted, it can be modified even if only slightly, and it can be silently corrupted. All of these things mean you will get a different hash, meaning you will never know the password again. I'm certainly not indicating that the approach presented is not without pitfalls. However, a 'lost' password via changed url and/or grabbed file is hardly a 'real' problem. Most, if not all, web services providers --both third party as well as self-hosted-- have some sort of password reset function. Usually this reset function is through a nonce sent to an email address on file with the service. So, worst case scenario for the 'lost' password, is to reset the password. >a working internet connection creates all sorts of potential issues. Agree... sort of ... It may be assumed that one has a working Internet connection to utilize the password to begin with. Overall, I'm of the opinion that many individuals and professionals are penny wise and pound foolish when it comes to passwords versus actual security. Sometimes it's necessary to remember that a secure system is one that doesn't function. For example, if I encrypt all my data with a secure one way hash and discard the original data, then all my data are 'safe'... even from me. However, that's not very useful. A good password is one that someone can remember... because that's a password that can be used. |
| relativ6 Jan 16, 2017 4:26 PM EDT |
I know the idea is frivolous, that's why I said it's only maybe useful. As stated in the article, the whole idea of it was inspire thought. It looks like it was a success. Thanks for reading, Darren |
| relativ6 Jan 16, 2017 4:35 PM EDT |
and to jdixon: tinyurl dot com slash second-light-take-a-right |
| AwesomeTux Jan 16, 2017 5:12 PM EDT |
dotmatrix wrote:I'm certainly not indicating that the approach presented is not without pitfalls. However, a 'lost' password via changed url and/or grabbed file is hardly a 'real' problem. Most, if not all, web services providers --both third party as well as self-hosted-- have some sort of password reset function. Usually this reset function is through a nonce sent to an email address on file with the service. So, worst case scenario for the 'lost' password, is to reset the password. Assuming the file you used to create the password for your e-mail address account isn't also lost or damaged, but I agree. dotmatrix wrote:Agree... sort of ... It may be assumed that one has a working Internet connection to utilize the password to begin with. I was more implying that it's a problem if Wikimedia Commons/etc or your own website is down or slow. dotmatrix wrote:A good password is one that someone can remember... because that's a password that can be used. I agree. And while this approach is certainly interesting, my problem with it is that while you may be able to easily remember what image is your password and be able to retrieve it from anywhere, problems outside of your control may result in a different hash password. Whereas generating a random password, with say, "uuidgen | sha256sum" and storing it with the rest of your passwords in a proper GPG protected password manager is a far more reliable solution. |
| AwesomeTux Jan 16, 2017 5:13 PM EDT |
relativ6 wrote:It looks like it was a success. Indeed. |
| dotmatrix Jan 16, 2017 5:41 PM EDT |
>Whereas generating a random password, with say, "uuidgen | sha256sum" and storing it with the rest of your passwords in a proper GPG protected password manager is a far more reliable solution. That's correct... however, you could also:
|
| AwesomeTux Jan 16, 2017 6:08 PM EDT |
dotmatrix wrote:That's correct... however, you could also: That's a reasonable approach as well. Although, personally I would probably choose a spreadsheet for passwords. dotmatrix wrote:Wouldn't this all just be easier if everyone would just realize that GNU/Linux is the best OS? And that PGP keys should be the universal authenticator? Yes, I agree. However, it's more likely we will move more towards phones and tablets being the primary computing device, and have all authentication rely on something physical like a fingerprint or retina scanner long before the world would make this much sense. |
| dotmatrix Jan 16, 2017 7:17 PM EDT |
>...something physical like a fingerprint or retina scanner long before... Unfortunately, I don't believe in biometrics. Perhaps, I've read "Angels and Demons" too many times and watched "V for Vendetta" once too often... I think I'm going to use a variation and combination of your spreadsheet and the sha256sum idea. Really... The end state solution will be an encrypted text file sitting on one my servers. A cron job will 'sha' something locally generated and place the result in a file. Then the file will be encrypted with my own public PGP key and placed on a retrievable but unindexed location. File contents will be: a text table like this Password | Create date | Current | URL -----------+---------------+-----------+-------------------- sum1 | Date 1 | | https://web1.tld -----------+---------------+-----------+-------------------- sum2 | Date 2 | X | https://web1.tld -----------+---------------+-----------+-------------------- sum3 | Date 3 | X | https://web2.tld |
| relativ6 Jan 16, 2017 10:05 PM EDT |
@dotmatrix: https://www.youtube.com/watch?v=At7I88VgOXE |
| cybertao Jan 18, 2017 5:07 AM EDT |
Rather than producing a password from an image, I'd be more inclined to hide a password in the image. Such as generating a key and embedding it in the least significant bit of the raw pixel data. Then extracting it from the raw pixel data to retrieve it.
Images will obviously need to use a lossless encoding format. That way your password still looks like an image while still having the advantage of being as random as the generator you use. |
| dotmatrix Jan 18, 2017 7:57 AM EDT |
>Rather than producing a password from an image, I'd be more inclined to hide a password in the image. This is a actual image tracking method. Many images on the Internet and in email have embedded 'call home' features. Simply displaying the image causes a notification to be sent to the owner of the embedded tracker. https://keen.io/docs/data-collection/image-beacon/ This is yet another excellent reason to avoid using 'webmail' services and to always view all your email in a separate client in plain text mode only... no html, not ever. |
| gus3 Jan 18, 2017 1:26 PM EDT |
@cybertao, that's called steganography. |
| NoDough Jan 18, 2017 4:03 PM EDT |
dotmatrix wrote:This is a actual image tracking method. Many images on the Internet and in email have embedded 'call home' features. Simply displaying the image causes a notification to be sent to the owner of the embedded tracker. I think you misunderstand image beacons. They are simply image links in messages pointing back to an image on a web server. Server access logs generate a count of message readers, IP addresses, and email addresses (if the links are sufficiently complex.) No code is stored in the images themselves. |
| dotmatrix Jan 18, 2017 8:03 PM EDT |
@NoDough: Oh... yeah... wrong link... This may be a bit better: http://photosecrets.com/track Digital Watermark wrote:If you want to track your images online, the best way to do it is with a secret tracking code embedded within the image itself. You can use “digital watermark” software to hide inside image pixels, and a “spider” (image crawler) website to monitor any appearances on the Internet. If a copy of your image is detected, you are alerted. Of course, such a service comes with a price. I see the steganography note above too... I'm not in this particular business, but have read about it. So, pardon the nomenclature slippage. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!