Sponsored Content
Full Discussion: Storing Passwords
Top Forums Web Development Storing Passwords Post 302928982 by jim mcnamara on Tuesday 16th of December 2014 04:44:55 PM
Old 12-16-2014
My only comment is:

Key management is an absolute pain in the butt.

Regarding keys -- When not in use (ie standing somewhere) the half-keys should be encrypted - both on the user side and the system side. Otherwise they are sitting ducks. Largely for internal attacks. Because internal people are less likely to set off security alarms or be seen in scans.

Whenever someone cracks your code for the key encryption algorithm, then they win. Period.

IMO, in this situation you have to affix value as an ROI to an operation. The ROI is the return on investment - your time, money, and effort.

There is always somebody who will claim such and such can be cracked. This is fog.
Unless forward perfect secrecy is mandated take a value-based approach.

And if theoretical cracking may be true: are you providing code where FIPS 140-3 is mandated? FIPS 140-3 - Wikipedia, the free encyclopedia

If not mandated, then what you try to do is make it hard to crack what you have done to encrypt things. Is it worth the costs of getting to perfect? - if it exists.

If you use a decent block cipher, you are good. If somebody can reverse engineer code, or get your source easily, then most things you can do are pointless. Shell coders love source. That is the ROI I'm talking about. Spend resource in several areas for much bigger return.

This is a values call, not something completely subject to theorematic analysis. It ain't black and white.

And. key-keeping and encryption is only 1/20th of security. User hygiene (keep malware off user desktops), least privilege, password quality and ageing, and all sorts of physical security methods are required, i.e., VPN, firewall, DMZ, carefully controlled access to tapes and data centers, locked doors and file cabinets, etc.

Bottomline:
Make it hard enough on the bad guys so they go somewhere else.
If the equivalent of a stuxnet is attacking your system, you are dead. No matter what you do.
 

9 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Passwords

I am running unix 11.xxx....How do you change a user password. The previous vs was passwd at the command prompt. This no longer works. Thanks for the help (3 Replies)
Discussion started by: turner.rd
3 Replies

2. Shell Programming and Scripting

Hide Passwords

Is there a way not to display the password in the sys out when your korn shell script logs into sqlplus? (3 Replies)
Discussion started by: lesstjm
3 Replies

3. UNIX for Dummies Questions & Answers

sqlplus and passwords

Hope I'm in the right place to ask this. ... and I'm a total noob by the way. When changing an account password through telnet, everything seems fine. I can telnet back in afterward, but if I try to use sqlplus to get in it tells me password invalid. If I try to get in through sqlplus with the... (1 Reply)
Discussion started by: tazman4
1 Replies

4. AIX

passwords encryption

I want to store a password of a user in a encrypted format and the use that encrypted password in my shell scripting. can any one of you let me know how to do it. Thanks in advance (0 Replies)
Discussion started by: kalpana.anuga
0 Replies

5. UNIX for Advanced & Expert Users

About unix passwords.

How the unix is maintaining the password ? How it does the encryption and how the passwords are stored in the system and where it is stored ? How it is better when compared to other OS ? (1 Reply)
Discussion started by: nagalenoj
1 Replies

6. OS X (Apple)

Storing ssh passwords/keys in keychain

Can anyone tell me how to set up ssh and keychain so when I connect to the remote system it uses keychain for the password or public key? The remote system is FreeBSD 8.0. Do I need to setup anything else on that end? Cheers. (0 Replies)
Discussion started by: Haggardly
0 Replies

7. Shell Programming and Scripting

passwords

Dear all, I need to automate/script a user password change process. I'm helpless cannot use expect since it's not installed and cannot install it either. Do i have an alternative. I can store the password in a file and that would be the password that would be set to all the users. If not i don't... (1 Reply)
Discussion started by: earlysame55
1 Replies

8. UNIX for Advanced & Expert Users

When did UNIX start using encrypted passwords, and not displaying passwords when you type them in?

I've been using various versions of UNIX and Linux since 1993, and I've never run across one that showed your password as you type it in when you log in, or one that stored passwords in plain text rather than encrypted. I'm writing a script for work for a security audit, and two of the... (5 Replies)
Discussion started by: Anne Neville
5 Replies

9. HP-UX

Passwords and shadows

version 11.22 1 - In this version there is the shadow file by default?. If so why when I search the file I get "No / etc / shadow file found"? 2 - What does the "*" in etc / password? at the beginning of each password? (1 Reply)
Discussion started by: shinju15
1 Replies
Crypt::Eksblowfish::Uklblowfish(3pm)			User Contributed Perl Documentation		      Crypt::Eksblowfish::Uklblowfish(3pm)

NAME
Crypt::Eksblowfish::Uklblowfish - Blowfish cipher with unrestricted key length SYNOPSIS
use Crypt::Eksblowfish::Uklblowfish; $block_size = Crypt::Eksblowfish::Uklblowfish->blocksize; $key_size = Crypt::Eksblowfish::Uklblowfish->keysize; $cipher = Crypt::Eksblowfish::Uklblowfish->new($key); $block_size = $cipher->blocksize; $ciphertext = $cipher->encrypt($plaintext); $plaintext = $cipher->decrypt($ciphertext); $p_array = $cipher->p_array; $s_boxes = $cipher->s_boxes; if($cipher->is_weak) { ... DESCRIPTION
An object of this type encapsulates a keyed instance of the Blowfish block cipher, ready to encrypt and decrypt. However, if you're looking for an implementation of Blowfish you most likely want Crypt::Eksblowfish::Blowfish. This class differs from the standard Blowfish in that it accepts some keys that Blowfish officially does not permit. Blowfish is a symmetric cipher algorithm designed by Bruce Schneier in 1993. It operates on 64-bit blocks, and takes a variable-length key. Officially the key can vary from 32 bits (4 octets) to 448 bits (56 octets) in increments of 8 bits (1 octet). In fact the algorithm can easily operate on a key of any number of octets from 1 (8 bits) to 72 (576 bits). Some implementations don't enforce the official key length limits, and so for compatibility it is sometimes necessary to handle a Blowfish key of a prohibited length. That is what this class is for. The "Ukl" in the name stands for "unrestricted key length". Using a very short key is generally a bad idea because there aren't very many keys of that length and so it's easy for an attacker to try them all. The official 32-bit minimum for Blowfish was already far too short for serious security at the time that Blowfish was designed. (A machine to crack 56-bit DES keys by brute force in a few days each was publicly built only five years later.) Do not base your security on the secrecy of a short key. Using overlong keys has more interesting effects, which depend on internal features of Blowfish. When the key exceeds 64 octets (512 bits), varying key bits past that length results in subkeys which have predictable relationships. There is also some possibility of equivalent keys when the keys exceed 64 octets and differ only in the first 8 octets (64 bits). These phenomena have not been extensively studied in the open literature, so it is difficult to judge the degree of cryptographic weakness that results from them. It is clear that beyond some length Blowfish keys do not have as much strength as their length would suggest, and it is possible that overlong keys have specific weaknesses that render them weaker than shorter keys. If choosing a key for security, it is advised to stay within the official length limit of 56 octets. In summary: using Blowfish keys of officially-unsupported lengths causes security problems. If you are using Blowfish for security, and have the choice, use a key of an officially-supported length (and a standard implementation such as Crypt::Eksblowfish::Blowfish). Use out-of-range key lengths (and this class) only for compatibility or cryptanalytic reasons. CLASS METHODS
Crypt::Eksblowfish::Uklblowfish->blocksize Returns 8, indicating the Blowfish block size of 8 octets. This method may be called on either the class or an instance. Crypt::Eksblowfish::Uklblowfish->keysize Returns 0, indicating that the key size is variable. This situation is handled specially by "Crypt::CBC". CONSTRUCTOR
Crypt::Eksblowfish::Uklblowfish->new(KEY) Performs key setup on a new instance of the Blowfish algorithm, returning the keyed state. The KEY may be any length from 1 octet to 72 octets inclusive. METHODS
$cipher->blocksize Returns 8, indicating the Blowfish block size of 8 octets. This method may be called on either the class or an instance. $cipher->encrypt(PLAINTEXT) PLAINTEXT must be exactly eight octets. The block is encrypted, and the ciphertext is returned. $cipher->decrypt(CIPHERTEXT) CIPHERTEXT must be exactly eight octets. The block is decrypted, and the plaintext is returned. $cipher->p_array $cipher->s_boxes These methods extract the subkeys from the keyed cipher. This is not required in ordinary operation. See the superclass Crypt::Eksblowfish::Subkeyed for details. $cipher->is_weak This method checks whether the cipher has been keyed with a weak key. It may be desired to avoid using weak keys. See the superclass Crypt::Eksblowfish::Subkeyed for details. This method does not detect any cryptographic weaknesses that might result from the related-key properties and other features of overlong keys. SEE ALSO
Crypt::Eksblowfish::Blowfish AUTHOR
Eksblowfish guts originally by Solar Designer (solar at openwall.com). Modifications and Perl interface by Andrew Main (Zefram) <zefram@fysh.org>. COPYRIGHT
Copyright (C) 2006, 2007, 2008, 2009, 2010 Andrew Main (Zefram) <zefram@fysh.org> The original Eksblowfish code (in the form of crypt()) from which this module is derived is in the public domain. It may be found at <http://www.openwall.com/crypt/>. LICENSE
This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself. perl v5.14.2 2011-11-15 Crypt::Eksblowfish::Uklblowfish(3pm)
All times are GMT -4. The time now is 02:08 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy