The UNIX and Linux Forums  
Hej och välkommen från USA till UNIX och Linux Forum! Tack för ditt besök och gå med i vår globala gemenskapen.

Go Back   UNIX och Linux Forum > Särskilda Forum > Säkerhet
.
google unix.com



Säkerhet Diskutera UNIX och Linux-dator-och nätverkssäkerhet, cybersäkerhet, cyberattacks, IT-säkerhet, CISSP, OWASP och mycket mer.

Mer UNIX och Linux Forum Ämnen Du kan hitta Helpful
Tråd Thread Starter Forum Svar Senaste Inlägg
SFTP lösenord automation jaycheetwood Shell-programmering och Skript 3 02-25-2009 04:07
AIX 5.2/5.3 - rootvg på SAN disk - och nackdelar jjgarrot AIX 6 11-18-2008 04:43
AIX SDD & MPIO Jämförelse (Pros Cons) applejuice AIX 0 03-10-2006 12:39
NFS-och nackdelar mcateriny AIX 1 04-26-2004 10:30
Unix-och nackdelar Kchalk UNIX for Dummies Frågor & Svar 5 01-27-2001 09:59

Closed Thread
English Japanese Spanish French German Portuguese Italian Dutch Swedish Russian Norwegian Hungarian Hebrew Danish Bulgarian Greek Powered by Powered by Google
 
LinkBack Thread Tools Sök i denna tråd Rate Thread Visningslägen
  #1 (permalänk)  
Old 03-09-2009
sudharma sudharma is offline
Registered User
  
 

Join Date: Jul 2008
Inlägg: 18
Thumbs up Lösenord Automation proffsen / CONS

föräldrar,

Jag har en skyddsrelaterad fråga till alla er. Vänligen dela med dig av dina synpunkter till mig.

Jag har en situation där jag blev ombedd att automatisera lösenord i min ansökan, som löper ut var 6 månader. I detta fall jag behöver för att generera ett slumpmässigt lösenord och ange lösenordet på vissa databas / system (krypterad) och använda detta lösenord i min ansökan. På så sätt ägare till konto kommer inte att känna till lösenordet också.

Mitt argument är att i första hand bör vi inte automatisera lösenord ändras automatiskt när expiary. Andra att ändra lösenord automatiskt lösenordet förändring är inte ansvarig och i senare skeden skulle vi inte veta vem som ändrat lösenordet förra gången. När jag tänker på att ändra lösenord Jag tror att kontot ägare bör responsiable för att hålla lösenord på ett hemligt / krypterad form.


Var vänlig och dela med dig av dina tankar om du hade haft en sådan situation beofre och vad är bästa sättet att hantera denna situation.


Hoppas hit från din expertese.


Skål
Sudharma.
  #2 (permalänk)  
Old 03-09-2009
pludi's Avatar
pludi pludi is offline Forum Staff  
Moderator
  
 

Join Date: Dec 2008
Ort:. Tillhör
Inlägg: 1871
Om det är ett lösenord för ett konto som endast används för automatiserad behandling, en utgången av 6 månader är lite mycket, särskilt om det konto ägare inte behöver känna till lösenordet (varför finns det en i alla fall). I detta fall jag hellre välja ett mycket, mycket komplicerade lösenord (max ut längd, använda specialtecken så mycket som möjligt ... något liknande ]? fb6 # Z8 "2a [(? (Cl + $? ) Som är giltig för de närmaste 2 åren eller så.

Eller ännu bättre, om att lösenord används för att fjärrsystem ansluta till ett system, släpp den helt och hållet byta till öppen nyckel autentisering med minst 2048 bitarsnycklar, dessa bör vara rädda för det kommande decenniet eller så (bara inte använda en gamla Debian för att generera dem)
  #3 (permalänk)  
Old 03-09-2009
sudharma sudharma is offline
Registered User
  
 

Join Date: Jul 2008
Inlägg: 18
Tack så mycket för ditt svar Pludi. Det var informativt.

Skål
Sudharma.
Closed Thread

Komihåglista

Thread Tools Sök i denna tråd
Sök i denna tråd:

Avancerad sökning
Visningslägen Betygsätt denna tråd
Betygsätt denna tråd:

Utstationering Regler
Du får inte efter nya trådar
Du får inte efter svar
Du får inte skicka bilagor
Du får inte redigera dina inlägg

BB-kod är
Smilies är
[IMG] kod
HTML-koden är Av
Trackback är
Pingbacks är
Refbacks är




Alla tider är GMT -4. Klockan är nu 04:08.


Powered by: vBulletin, Copyright © 2000 - 2006, Jelsoft Enterprises Limited. Översättningar Powered by .
vBCredits v1.4 Copyright © 2007 - 2008, PixelFX Studios
UNIX och Linux Forum Innehållet upphovsrättsskyddat © 1993-2009. All Rights Reserved.Ad förvaltning RedTyger

Content Relevant webbadresser från vBSEO 3.2.0