The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,982 other followers

Archive for the ‘Hashing’ Category

Hardening: sshd_config – How to configure the OpenSSH server | SSH.COM

Posted by jpluimers on 2020/06/05

If you want to harden your ssh server, read at least [WayBack] sshd_config – How to configure the OpenSSH server | SSH.COM.

After that use some ssh tools to check your config from the outside world. They work in a similar way as the TLS/SSL/https scans from Source: SSL Server Test (Powered by Qualys SSL Labs) or these console based scans and documentation references:

Simiarly for SSH:

Then read further on more in depth SSH topics around key management:

–jeroen

 

Posted in Encryption, Hashing, https, HTTPS/TLS security, OpenSSL, Power User, Security, testssl.sh | Leave a Comment »

OpenSSH keygen guidelines

Posted by jpluimers on 2020/05/01

Verify [WayBack] OpenSSH: Key generation before generating keys.

At the time of grabbing it was this (for the mozilla tag; use another tag if you prefer):

# RSA keys are favored over ECDSA keys when backward compatibility ''is required'',
# thus, newly generated keys are always either ED25519 or RSA (NOT ECDSA or DSA).
$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"

# ED25519 keys are favored over RSA keys when backward compatibility ''is not required''.
# This is only compatible with OpenSSH 6.5+ and fixed-size (256 bytes).
$ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"

This was not changed based on [WayBack] Key generation: pass-a and -o argument? · Issue #68 · mozilla/wikimo_content · GitHub: a discussion on the KDF rounds (-a parameter) and storage format (-o parameter).

This is slightly less strong than in [WayBack] Upgrade Your SSH Key to Ed25519 | Programming Journal, but seems to be OK when writing this in 2018.

For comparison, a similar discussion is at [WayBack] public key – How many KDF rounds for an SSH key? – Cryptography Stack Exchange.

In practice, I am not for one ssh ID per host, but I use different tags depending on where the ssh ID applies. More discussion on this is at [WayBack] privacy – Best Practice: ”separate ssh-key per host and user“ vs. ”one ssh-key for all hosts“ – Information Security Stack Exchange

Based on the above, I also learned about this password generator: [WayBack] GitHub – gdestuynder/pwgen

–jeroen

Posted in *nix, *nix-tools, Encryption, Hashing, Power User, Security, ssh/sshd | Leave a Comment »

A cheat-sheet for password crackers

Posted by jpluimers on 2018/07/30

Interesting: [WayBackA cheat-sheet for password crackers

Via: [WayBackJoe C. Hecht – Google+

–jeroen

Posted in *nix, *nix-tools, Hashing, md5, Power User, Security, SHA, SHA-256, SHA-512 | Leave a Comment »

Client-Side Password Hashing – DelphiTools

Posted by jpluimers on 2018/05/03

Interesting thought on client-side password hashing: [Archive.isClient-Side Password Hashing – DelphiTools.

I’ve ambivalent feelings on it, especially since it will expose salt and other settings to the client.

On the other hand it tremendously helps when there are transparent proxies in between. Read the article for full details; here is just one quote below.

Maybe dual hashing would be in place: once at the client to prevent plain-text to go over MITM channels, and a second hash server side with different settings like salt to prevent brute force attacks.

I need to give this more thought.

The quote:

If you are using a regular Windows and a regular browser, access to HTTPS will go through the regular certificate chain, using regular certificate authority. You also benefit from extra security layers like Public Key Pinning.

But when a custom Root CA is installed, all that goes through the window: the custom Root CA allows the corporate proxies to issue “valid” certificates for any website (even google.com and the rest), and the public key pinning features are disabled:

How does key pinning interact with local proxies and filters?

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. 

A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

All the major browsers have a similar behavior… because it is required to allow transparent proxies. And transparent proxies are the means through which the legal logging requirements are fulfilled.

So besides introducing a major MITM opportunity, this also means that there are legally-required corporate logs somewhere of all that went through HTTPS… including plain text passwords, if you did not hash them on the client-side.

These logs will have varying degrees of security when in the corporate domain… and next to none if they are ever requested by the legal system for an investigation.

–jeroen

 

Posted in Algorithms, Design Patterns, Development, Hashing, Power User, Security, Software Development | Leave a Comment »

~650-thousand accounts exposed because of md5 hashing: Font sharing site DaFont has been hacked, exposing thousands of accounts | ZDNet

Posted by jpluimers on 2017/05/19

Over 98 percent of the passwords were cracked, thanks to the site’s poor password security.

No this isn’t just the hacked font

Source: [WayBackFont sharing site DaFont has been hacked, exposing thousands of accounts | ZDNet

via: [Archive.isFont Sharing Site DaFont Has Been Hacked, Exposing Thousands of Accounts – Slashdot

–jeroen

Read the rest of this entry »

Posted in Encryption, Hashing, md5, Power User, Security | Leave a Comment »

 
%d bloggers like this: