New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
That's not how security works.
At the end of the day it's about x bytes of data, about entropy, about looking pseudo-random. In fact, a e.g. 96-byte random hex-string not only is not worse than a public key but actually better ("more secure"), albeit needlessly better.
Also the password is just (symmetrically) encrypting the key and does not add to the security of SSH session establishment.
Side note for those who like to use passwords: make your actual pass phrase (as seen by the server) the hash of what you perceive as your password (and can remember well).
For example 'Jason1990' (first name + year of birth) is a really sh_tty pass phrase - but easy to remember for Jason - but SHA512('Jason1990') is a quite good pass phrase, especially when a salt is used.
Thanks for the detailed response. Your thoughts are practical.
It's back on stock right now
shows OOS
Disabling password login has the benefit of discouraging brute force attempts that use up resources (RAM, CPU, bandwidth, log spam), etc.
On a dedicated PC, this isn't so bad. But a shared server with hundreds of accounts getting brute force logins thousands per account per day just wastes resources.
You frequently speak in double negatives, is that a Russian thing? That's generally taught in English to be avoided.
What? It's an additional requirement of proof of user even before the SSH session begins. Of course it adds to the security.
And you've just been broken by AI. There was an excellent episode from Vice where they looked at how AI analyses everything about a person, habits, social, mental, etc and tailors the brute force attempts. It was fairly successful in short time.
The key, though? Won't be brute forced or AI'd.
As usual you know everything better - and as usual you are dead-wrong.
For a start, I did not even assert what you "understood". What I said was "does not add to the security of SSH session establishment.". The password for SSH keys does not make SSH more secure but it protects you in case your private key is "stolen".
Similar for your other point. I explicitly wrote that 'Jason1990' is a sh_tty pass phrase and what I suggested was to actually use a crypto-hash and use its output as the real password - and ( clearly spelled out) preferably with a salt.
Here is the sha-256 hash of a simple string: "e7d936b6622ffaecf99582b0ece755ce96259e58848647bd5bd2626ba400c3cb"
Now, ask your AI and tell me the string I hashed. Well noted just 256 (rather than 512 bits as I had suggested) and without a salt so it should be a breeze for your AI.
TL;DR Don't worry, one can use a good crypto-hash, again, min 256 bit and preferably salted, to get a random looking good entropy, secure password based on an easy to remember (but sh_tty as a pass phrase" "password" like e.g. 'Jason1990'.
That said, of bloody course, a less sh_tty pass phrase as input is preferable.
Having your car doors locked is more secure from being stolen from being hotwired than a car with unlocked doors.
whoosh you used a predictive algorithm. It isn't trying to get the output, just the inputs and the algorithm and then it can get the output the same way as you.
Yeah right. Because we know from movies what AI is capable of.
I give up, just continue to extend your "knowledge" via "Vice" and movies ... while I'll stay a mere mortal bound by boring things like math. Have a nice evening.
While this is probable, what @jsg actually means is that you can use the transformed string as the password instead of the initial sh_tty one. In this case you have to remember an easy password and you also need a software to calculate the sha256 each time you want to use it. (except if you have some kind of brain damage and you can remember those 32 bytes)
Then what is actually stored in the system is a double-hash of the initial sh_tty password, instead of a single hash of a sh_tty password that may be brute-forced with dictionary attacks or other exotic means like what you describe.
i.e assuming that the system keeps a sha512 hash of the user password, the final hash is
p = SHA512(SHA256("Jason1990"))While it's an interesting trick, I think it's better not to use sh_tty passwords in the first place
Just use an excel sheet and write everything down and encrypt the file.
Well, firewall the SSH port, use something like wireguard, to access the machine.
But make sure, your VPN is redundant.
Use different keys, encrypt stuff.
So even if someone manages to steal your keys, they still need VPN access.
If you are that paranoid, enable 2FA on SSH.
I fully understand what jsg is saying. You don't need to brute force the double hashed result and I wasn't saying the attacker would. I'm saying they'll do such a deep psychological dive into you, that they'll think like you. For example, some variation on favourite band or first fuck, etc. Or someone who likes hashing things.
When crackers are making keygens for expensive software, they're not breaking the encryption, they are stealing the functions/algorithms that take the input and generates valid output.
For the record, I subscribe to that cartoon's message. Random words, not:
Yeah right, and they'll also do such a deep psychological dive into the random generator, that they'll think like random. Because AI and "Vice".
And being at it, the AI also will use artificial rainbow tables on arrays of virtual artificial storage of Exa- or even Zeta-Bytes size. Because AI and "Vice".
And there still are some little issues like hashing results looking like random or like symmetric crypto output but being very different in fact, because encryption by definition is reversible while hashing by definition is irreversible. But hey, that's just math and math means nothing when AI enters the stage!
There's just one tiny weakness:
Somehow the AI so far failed to crack this really really (intentionally) simple riddle. And I even committed the (quite grave) sin of not using a salt.
So, you "modern", "Vice" students, you'll stay with your super AI - and I'll stick with boring math and science.
Why mention an RNG where your example of using a known first name and birth year would not be the equivalent of using RNG? whoosh
Fuck, you're basic. Rather than learn something new, you try and gaslight others instead of just educating yourself. As explained several times, it's not trying to brute force the hashed result. It will build its own tables based on keywords from your life and significantly decrease the attempts at your password.
Further evidence you don't know wtf is going on. An AI that is trying to login to your SSH server using password is just going to enter the same string as you would. It's guessing what password you might start from and you made that possible by using first name and year. Base it on the serial found on a can of coke one day and AI wouldn't know to add that to the mix.
What AI are you talking about? Like some "AI" trolls the net and randomly checks this forum? What a fucking stupid thing to say.
Jsg, you are seriously fucked in the head. You're seriously defending a password based on the person's first name and date of birth. You shouldn't be allowed anywhere near security.
Of bloody course you even failed to really understand what I said.
Let's keep it simple: you continue your "wooosh" route and I continue my boring math and actually implementing crypto algorithms route.