Rasgele bir şifre oluşturma; bu neden taşınabilir değil?

21

Rasgele bir şifre oluşturmak istiyorum ve bunu şöyle yapıyorum:

</dev/urandom tr -dc [:print:] | head -c 64

Ubuntu'yu çalıştıran dizüstü bilgisayarımda bu, yalnızca istendiği gibi yazdırılabilir karakterler üretiyor. Fakat Red Hat Enterprise Linux çalıştıran okulumun sunucusuna ssh atıp orada çalıştırdığımda 3!ri�b�GrӴ��1�H�<�oM��&�nMC[�Pb�|L%MP��9��fL2q��IFmsd|l�K, hiç yapmayacak gibi çıktılar alıyorum . Burada yanlış giden ne olabilir?

— Taymon
kaynak

34

Bu senin yerel ve tr sorunun.

Şu anda, GNU tr tamamen sadece tek baytlık karakterleri desteklemektedir. Dolayısıyla, çok baytlı kodlamaları kullanan yerel ayarlarda, çıktı garip olabilir:

$ </dev/urandom LC_ALL=vi_VN.tcvn tr -dc '[:print:]' | head -c 64
`�pv���Z����c�ox"�O���%�YR��F�>��췔��ovȪ������^,<H ���>

Kabuk, çok baytlık karakterleri doğru yazdırır, ancak GNU tryazdırılamaz olduğunu düşündüğü baytları kaldırır.

Sabit olmasını istiyorsanız, yerel ayarı ayarlamanız gerekir:

$ </dev/urandom LC_ALL=C tr -dc '[:print:]' | head -c 64
RSmuiFH+537z+iY4ySz`{Pv6mJg::RB;/-2^{QnKkImpGuMSq92D(6N8QF?Y9Co@

— cuonglm
kaynak

14

+ 1, bunun fark etmemi sağladı (Unix / Linux'ta kabukları yalnızca 30 yıl kullandı), stdin / stdout / stderr yönlendirmesinin uygulanacağı komuttan sonra konumlandırılması gerekmediğini fark ettim .

— Anthon,

Garip bir yerel ayar ayarlanmışsa, yalnızca yorum olmasa da, kabuk hala doğru olmasa da karakterleri doğru şekilde yazdıramaz mı? En azından yetkin bir kabuk (elbette xterm hariç)?

— orion

2

@ orion: kabuk karakterleri doğru basar. Bu durumda, bu tr sorun. Yazdırılmadığını düşündüğü baytları temizledi, sonucu garip hale getirdi.

— cuonglm

@orion Üniform bir şekilde rastgele bir bayt akışı, genel olarak, iyi oluşturulmuş bir UTF-8 karakter kodlamalarının üniform bir şekilde rastgele bir akışı olmayacaktır .

— zwol

Ayrıca, şifrenizde hangi boşluklar yoksa, :graph:yerine aşağıdakileri kullanmalısınız :print::</dev/urandom LC_ALL=C tr -dc '[:graph:]' | head -c 64

— edan

11

Bunun yerine düşünün

$ dd if=/dev/urandom bs=48 count=1 status=none | base64
imW/X60Sk9TQzl+mdS5PL7sfMy9k/qFBWWkzZjbYJttREsYpzIguWr/uRIhyisR7

Bunun iki avantajı var:

~ 8KB'yi değil rastgele aygıttan yalnızca 48 bayt okudunuz; Aynı ana bilgisayardaki diğer işlemlerin rasgele sayılara ihtiyacı varsa, bir kerede boşaltılmış 8KB ciddi bir sorun olabilir. (Evet, tartışmasız hiç kimse engelleyici rasgele cihazı kullanmamalı, ancak insanlar kullanmalıdır .)
Çıktısı base64özel anlamlara sahip neredeyse hiç karakter içermiyor. (Hiç hiçbiri, yapışkanlık için | tr +/ -_örnekte olduğu gibi ucunda ve () bayt emin sayıda yapmak giriş için base643 bir katı olan)

Bu şekilde oluşturulan bir şifre tam olarak 384 bit entropiye sahiptir, bu sizin yaptığınızdan biraz daha azdır (log ₂ 96 ⁶⁴ ≈ 421.4), fakat çoğu amaç için fazlasıyla yeterli (256 bit entropi güvenli bir şekilde) Sun, " RSA anahtarları, AFAIK hariç " bölgeyi yakar .

— Zwol
kaynak

3

Diğer insanlar zaten yerelin ne [:print:]anlama geldiğini belirlediğine dikkat çekti . Ancak, yazdırılabilir karakterlerin tümü şifreler için uygun değildir (ascii'de bile değil). Gerçekten boşluk, sekme ve # $% ^ istemiyor musunuz? şifrenizde - hatırlamak sadece zor değil, aynı zamanda altta yatan kimlik doğrulama sistemi için potansiyel olarak tehlikelidir, bir giriş alanına girmeniz imkansız olabilir. Bu durumda, sadece "aklı başında" karakterleri manuel olarak seçmelisiniz:

LC_ALL=C </dev/urandom tr -dc '[:alnum:]_' | head -c 64

ya da sadece

</dev/urandom tr -dc 'A-Za-z0-9_' | head -c 64

Ya da daha iyisi, base64diğer cevaplarda önerildiği şekilde kullanın .

— Oryon
kaynak

Söz konusu parola asla insanlar tarafından girilmeyecek (eğer bunun yerine Diceware kullanıyor olsaydım) ve altta yatan sistemin problemsiz özel karakterleri kullanabildiğinden eminim. Yine de teşekkürler.

— Taymon

4

Söylediklerin tamamen yanlış. Kullanıcıları yalnızca ascii harfler, rakamlar ve alt çizgi kullanmaya zorlamak, alfabe boyutunu önemli ölçüde azaltır ve saldırganların şifrelerini kırmayı çok kolaylaştırır. İşlenemeyen ?veya ^ciddiye alınamayacak kadar kötü bir kimlik doğrulama sistemi .

— Bakuriu

2

Yetkilendirme sisteminiz veya giriş alanlarınız normal ASCII sembollerini boğarsa ... o zaman yanlış bir şey yapıyorsunuzdur ve özel bilgilerime güvenilmemelisiniz. Şifrelerinizde her türlü karakteri (boşluklar dahil) kabul etmemek için kesinlikle hiçbir neden yoktur.

— nzifnab

2

Görünüşe göre buradaki durum böyle değil, ancak insan girişi söz konusu olduğunda, sahibine benzersiz bir anlamı olan uzun bir alfanümerik şifreyi hatırlamak, daha kısa bir sembol kargaşasından çok daha kolaydır. Bu karakterleri çeşitli klavyelere girme sorunu da var (herkes birinci seviyeden ^ değil ve çoğu kişi bir geri tepmenin nerede veya ne olduğunu bile bilmiyor), giriş kutuları neredeyse kesinlikle sekme karakterini işleyemiyor ve şaşırtıcı sayıda web formu hala doğrulama hatalarına, sql enjeksiyonuna ve hatta belirsiz vaka duyarlılığına karşı hassastır.

— orion

1

Sadece bir not: C locale [:print:]sınıfın yok değil sekmeleri bulunur. Sadece [:alnum:]+ [:punct:]+ boşluktur (tek boşluk değil [:space:] ).

— jimmij

2

Ne dersin

tr -dc [:print:] < /dev/urandom | head -c 64 | strings

dizelerin urandom çıktısını yazdırılabilir biçimde yazdırması gerekir

— Blindstealer
kaynak

Bu verir-bash: /dev/urandom: Permission denied

— Anthon

özür dilerim önde gelen kedi unuttum

— Blindstealer

2

/dev/randomŞifreyi oluşturmak için neden kullandığınızın bir nedeni olup olmadığını bilmiyorum , ama acınızı hafifletmek için pwgen kullanmanızı öneririm.

$ pwgen -s 10 1

10 şifrenin uzunluğu.

http://man.cx/pwgen

— Daniel
kaynak

1

#Chars allowed in password (I don't like l,o,O, etc):
P="0123456789ABCDEFGHIJKLMNPQRSTUVWXYZabcdefghijkmnpqrstuvwxyz"

#Or such:
#P="a-zA-Z0-9"

head -c 8 < /dev/urandom | tr '\000-\377' "$P$P$P$P$P"
echo

Bu yöntem IMHO / dev / urandom'dan veri aldığında daha akıllıdır. $ P $ P $ P ... olarak yapıştırılan dizginin en az 256 karakter uzunluğunda olması gerekir.

— Alexander Kelner
kaynak