Lösenord är det huvudsakliga medlet för att skydda information och används överallt på en dator – från att logga in på ett konto till att auktorisera på sidor på sociala nätverk. En aktiv användare har så många olika säkerhetsnycklar att det är omöjligt att behålla alla i minnet. Det är här funktionen att spara lösenord i webbläsarinställningarna kommer till undsättning.

Det fungerar så här:

Nästa gång du öppnar den här sidan behöver du inte ange någonting; även om du loggar ut från ditt konto kommer alla rader i behörighetsformuläret att fyllas i. Men här avslöjas en allvarlig nackdel - låt oss ta reda på hur man ser ett lösenord som är dolt med asterisker, och om det är möjligt att göra detta alls.

Så du går till webbplatsen och ser lösenordet under asteriskerna. Det verkar som en bekväm sak - du klickar på "Logga in" och du behöver inte ange något annat, och andra användare ser inte ditt lösenord.

Ett lösenord täckt med asterisker är ett enkelt mål för hackning.

Kolla in det på din dator. Som ett exempel använder vi webbläsaren Google Chrome:

På samma sätt kan du se åtkomstnycklar till konton i andra webbläsare - Mozilla Firefox, Opera, Internet Explorer. Låt oss se hur detta görs i Mozilla för att fästa material:

Förresten, det är inte nödvändigt att ändra värdet tillbaka till "lösenord". Om du stänger sidan och sedan återvänder till den igen ser du att stjärnorna har kommit tillbaka. Men nu vet du vilka opålitliga beskyddare av personuppgifter de är.

Om du tror att detta är slutet på exponeringen av stjärnorna, har du djupt fel. Alla webbläsare har ett ännu bekvämare sätt att se lösenordet som du sparade när du först loggade in på sidan. Den här gången, låt oss ta Opera-webbläsaren som ett exempel:

Ett fönster kommer att visas med många webbadresser och data från olika konton. Vid första anblicken är allt bra: inloggningar, naturligtvis, visas, men istället för lösenord finns det asterisker som är bekanta för oss. Men om du klickar på en rad kommer du att se en Visa-knapp visas bredvid stjärnorna.

Ett klick och du ser säkerhetsnyckeln för sajten. Du kan avslöja alla lösenord, ta en skärmdump och du kommer inte ens att inse att dina lösenordsskyddade sidor nu är i fara. Inte bara Opera, utan även andra webbläsare delar sådan information. I Google Chrome, till exempel, kan en sådan skylt kallas på följande sätt:

I Mozilla Firefox öppnas en tabell med alla sparade åtkomstnycklar i avsnittet "Säkerhet" i inställningarna.

I andra webbläsare är situationen liknande - all data som du accepterar att lagras måste vara allmänt tillgänglig.

Men inte bara webbläsare lagrar data om användare, som användaren vänligen tillhandahåller och lagrar.

Alla program som kräver att du anger ett lösenord och inloggning erbjuder också att komma ihåg denna data för att inte ange den varje gång du startar den.

Följaktligen finns det speciella verktyg som låter dig se dessa sparade data. Sådana verktyg fungerar på samma princip, så låt oss ta Password Cracker-programmet som ett exempel. Den distribueras gratis och väger löjliga 45 KB.

På raden "Lösenord" i verktygsfönstret för lösenordsknäckare kommer den sparade säkerhetsnyckeln att visas i alfanumerisk visning.

Som du kan se nu är det inte svårt att ta reda på lösenordet som är gömt i webbläsaren, dolt med asterisker. Allt du behöver är tillgång till en dator och ett par minuters tid så att uppgifterna från dina konton hamnar i händerna på obehöriga.

Naturligtvis riskerar du i det här fallet att glömma ditt lösenord och inte komma in i den önskade profilen. Detta är dock inte skrämmande: vi har redan skrivit om hur du återställer ditt Gmail-lösenord, hur du tar reda på ditt Wi-Fi-lösenord, hur du återfår åtkomst till ditt konto i WarFace-spelet, etc. Om du kan logga in i brevlådan som kontot är registrerat till, eller har kopplat ett telefonnummer till din profil, kan du vid behov enkelt återställa ett glömt lösenord.

Men vad ska man göra med de säkerhetsnycklarna som du redan har sparat i webbläsarinställningarna? Rätt svar är att radera. När du tittade på lösenord genom inställningar borde du ha sett att funktionen för att spara koder kan inaktiveras. Rensa tabeller med lagrade nycklar, ta bort alla rader och avaktivera sedan själva funktionen.

Det finns inga liknande artiklar.

Så vår uppgift är att ställa in ett lösenord för att komma åt en viss sida. Låt oss börja med den mest primitiva metoden, så att säga, för skydd - några rader i JavaScript:

Var pass = prompt("Ange lösenordet:", ""); if (pass == null) window.location = "wrong.html"; else if (pass.toLowerCase() == "wwvsfc") window.location = "temp.html"; else window.location = "wrong.html"; Knep som att dölja ett skript i en separat fil med hjälp av en konstruktion förändrar ingenting i grunden.

Ett liknande system implementerat i Java:

Importera java.applet.*; importera java.awt.*; importera java.net.*; public class Password extends Applet( TextField login, password; String Login = "login"; String Password = "Password"; public Password() ( ) public void init() ( Panel panel = new Panel(); panel.setLayout(new GridLayout(2,2)); login = new TextField(20)); new Button("Ok")); public boolean action(Event evt, Object obj) ( if(evt.target instansof Button) (String s; if(login.getText().equals(Login) && password.getText() .equals(Lösenord)) ( s = "http://www.hackzone.ru/articles/ok.html" ; ) else ( s = "http://www.hackzone.ru/articles/bad.html"; ) försök ( getAppletContext().showDocument(ny(a) URL(er)); ) catch(Undantag e) ( password.setText (e.toString()); return true; return false)

Genom att inkludera denna applet på en sida kan du få något i stil med detta (alla efterföljande exempel använder ok.html och bad.html):

Det kan göras smartare, skapa en separat sida för varje användare, tvinga den att läsa data från en fil osv. Den grundläggande nackdelen är att när en person väl har landat på sidan han letar efter kan ingen hindra honom från att komma ihåg denna URL, så detta är ett engångsverktyg. Naturligtvis kan du gömma sidan inuti en ram så att URL:en inte visas i adressfältet, men du förstår vem detta skydd kommer från. Återigen går appleten helt till kunden och är i princip helt tillgänglig för forskning.

Lösningen baserad på användningen av CGI har inte den sista nackdelen. Ett enkelt Perl-skript ser ut ungefär så här:

#!/usr/bin/perluse CGI qw(:standard); $query = new CGI;$ok = "ok.html";$address = "bad.html"; $login = "login";$password = "lösenord"; $l = $query->param("login"); $p = $query->param("lösenord"); if(($p eq $password) && ($l eq $login))( $address = $ok;)print $query->redirect($address);

Användningsexempel:

För att hantera den första nackdelen kan du dynamiskt generera en ny sida baserad på den som är gömd någonstans inuti, utan att ge ut URL:en.

Ändrad kod:

#!/usr/bin/perluse CGI qw(:standard); $query = ny CGI; $ok = "ok.html"; $address = "bad.html"; $docroot = $ENV("DOCUMENT_ROOT"); $localpath = "/artiklar/"; $login = "login";$password = "lösenord"; $l = $query->param("login"); $p = $query->param("lösenord"); if(($p eq $password) && ($l eq $login))( $address = $ok;) skriv ut $query->header(); open(FL, $docroot.$localpath.$adress); while())(# Här kan du samtidigt ändra html-koden i farten# Varför? Tja, man vet aldrig... :) print $_;) close (FL);

Användningsexempel:

Som du kan se visas inte längre filens URL, om än på bekostnad av SSI (dock kan de bara fångas upp under utmatning och bearbetas manuellt, men även här kvarstår den teoretiska möjligheten att gissa URL, och). vi får inte glömma att alla möjliga bilder som ingår kan göra sidorna en otjänst - när man använder relativa vägar, förstås.

Slutligen, det mest pålitliga sättet att ställa in ett åtkomstlösenord är att använda serververktyg - det är inte för inte som folk gjorde dem, trots allt. Jag kommer att fokusera på två - Apache som den mest populära och IIS som också populär :)

Med IIS är allt ganska enkelt - skyddet utförs med NTFS, vilket naturligtvis begränsar kapaciteten för icke-serveradministratörer något. Tanken är följande: användaren IUSR_xxxx, under vars konto alla besökare på sajten arbetar som standard, nekas åtkomst till önskad fil/katalog. Därefter kommer endast de användare för vilka detta uttryckligen anges i Egenskaper->Säkerhet att ha tillgång till dessa filer. Det är tydligt att det är mycket bekvämare att kombinera dem i grupper. Det finns ett par subtiliteter här. För det första måste de angivna användarna ges inloggningsrättigheten lokalt (Policyer->Användarrättigheter i Användarhanteraren. För det andra, om du inte väljer WWW-tjänsten Grundläggande autentisering (Rensa text) i WWW-inställningarna, kommer endast Internet Explorer-användare att vara det. släpps in.

I Apache görs allt lite annorlunda. Skydd är inställt på katalognivå. Motsvarande direktiv kan placeras både i den allmänna php.ini-konfigurationsfilen och i .htaccess-filerna. Uppsättningen av direktiv är i båda fallen densamma, och för de flesta som hyr utrymme för en webbplats/sida på någon annans server är det första alternativet inte tillgängligt. Så du skapar en .htaccess-fil i katalogen som du planerar att begränsa åtkomst till och infogar sedan följande direktiv i den:

AuthType typ av kontroll– Basic brukar användas.

AuthName namn- anger namnet på området där användarnamn och lösenord är giltiga. Detta är samma namn som webbläsaren visar i lösenordsdialogrutan. Genom att ställa in ett sådant namn för olika kataloger kan du spara användarna tiden för att ange ett extra lösenord.

AuthGroupFile namn- anger namnet på filen där namnen på grupper och deras medlemmar är lagrade. Dess format:
grupp1: medlem1 medlem2 ...
grupp2: medlem3 medlem4 ...

AuthUserFile namn- anger namnet på filen med lösenord. För att generera det måste du i stort sett använda verktyget htpasswd från Apache-distributionen. Men åtminstone för vissa versioner av servern är detta format:
användare1: passwordhash1
användare 2: passwordhash2

Passwordhash kan enkelt erhållas med den vanliga Perl-funktionen:
$hash=krypt($pass,$salt);
där $pass är lösenordet, är $salt en tvåteckensträng som är involverad i att generera hashen.

Så det är fullt möjligt att automatisera processen att lägga till nya användare, ändra lösenord via html-formulär, etc.

kräver användare användare1 användare2 och kräver grupp användare1 användare2 låter dig ange vilka användare och grupper som ska ha tillgång till en given katalog.

kräver giltig-användare ger åtkomst till alla användare som anges i systemlösenordsfilen.

... , där metod i definierar en HTTP-metod. Till exempel begränsar det användningen av kapslade icke-direktiv till fall av användning av GET- och POST-metoderna (vanligtvis är detta mer än tillräckligt med kapslade direktiv kan kräva, beställa, tillåta och neka).

Ett annat par användbara direktiv är neka och tillåta - neka respektive tillåta åtkomst. De används ungefär så här:
förneka från alla
tillåta från 192.168

Som standard exekveras alla avslag först, sedan tillåts alla, så tillåt från alla ger åtkomst till alla användare, oavsett eventuella avslag. Ordningen kan ändras med orderdirektivet: order tillåter, neka .

deny from all går bra med den andra metoden att skydda sidor via CGI, det är detta direktiv som är bäst för att täcka alla slags lösenord för gästböcker, etc. När användaren försöker komma åt sidor från denna katalog kommer användaren att få ett meddelande om en icke-existerande sida.

Förresten, här i förbigående demonstreras oberoende felhantering: i detta fall kod 403, Förbjudet. De älskade 404 - Not Found och 401 - Unauthorized behandlas på liknande sätt. För att göra detta, lägg bara till ErrorDocument-direktivet till .htaccess URL-kod:
ErrorDocument 404 /cgi-bin/bad.pl
ErrorDocument 403 /cgi-bin/badaccess.pl
ErrorDocument 401 /cgi-bin/badaccess.pl

Allt skriptet gör är att generera ett felmeddelande med hjälp av miljövariabeln REQUEST_URI, så du kan bara peka på någon lämplig sida istället.

För det sista exemplet använder vi en .htaccess-fil med följande innehåll:

AuthType BasicAuthName TestAuthGroupFile /my/local/path/tgroupAuthUserFile /my/local/path/tuserrequire group test

Det finns bara en rad i tgroup-filen - test: inloggningstest, i användarfilen - krypterade lösenord för inloggning (lösenord) och test (test). Observera att när du går in på den här sidan igen förstår webbläsaren att den just har nått det här området och stör inte användaren med en onödig begäran om lösenord.

Detta är i korthet den minsta mängd information som krävs för att skydda webbsidor. Som praxis visar bör du mer eller mindre bara lita på lösningar baserade på de verktyg som servern tillhandahåller (och sedan tills ett annat hål upptäcks i servern), så om möjligt är det bättre att välja dem.

Enkla sätt att låsa en katalog eller filer med ett lösenord diskuteras. Hur man auktoriserar en användare genom cookies. Användaridentifiering genom sessionsmekanismen inbyggd i PHP4.

Jag bestämde mig för att beskriva sätt att skydda en del av webbplatsen med ett lösenord. Ämnet är faktiskt ganska stort, så för första gången kommer jag att begränsa mig till php+mysql-auktorisering.

Den allra första frågan som brukar dyka upp är hur man stänger katalogen med administrationsskript med ett lösenord. I det här fallet behövs inga krusiduller - en eller flera administratörer har samma rättigheter, och personligheter förändras sällan. Det enklaste sättet i den här situationen är att använda standardserverbehörighet - lägg .htaccess- och .htpasswd-filerna och skriv de nödvändiga parametrarna i dem.

Jag ska lägga till två saker. Den första är var .htpasswd-filen ska placeras. Experimentellt fick jag reda på att om till exempel sökvägen till ett dokument med ett felmeddelande (ErrorDocument) skrivs i förhållande till systemvariabeln DocumentRoot. Men sökvägen till lösenordsfilen (UserFile) skrivs i förhållande till ServerRoot. Såvitt jag förstår kan du inte sätta .htpasswd ovanför ServerRoot - "../" uppfattas inte. Allt detta görs för att du ska kunna placera en fil med lösenord, till exempel en nivå ovanför webbplatsens rotkatalog, så att det inte finns någon tillgång till filen från nätverket alls.

Det andra är att skriptet kan ta reda på vem som öppnar det och lösenordet: variablerna $PHP_AUTH_USER och $PHP_AUTH_PW.

Den största nackdelen med denna metod är att servern inte kan blockera lösenordsgissning (efter flera misslyckade inloggningsförsök uppmanas användaren att vänta en timme eller två, och under denna tid ignoreras samtal från hans IP-adress). Detta är skrivet i den officiella Apache-dokumentationen.

En annan nackdel är behovet av att skriva om filer med lösenord när du tar bort en användare eller introducerar en ny. Men om detta händer sällan är den här metoden ganska tillräcklig, och du behöver inte oroa dig för att skriva en auktoriseringsmekanism.

Detta är nödvändigt inte bara för att förenkla arbetet med ett stort antal användare och deras höga omsättning. Om du behöver behålla ytterligare information om användare, eller om du behöver flexibel differentiering av rättigheter, är det bättre att överföra behörighet till databasen.

Varje sida i ett stängt område innehåller en fil med följande kod:

$result = mysql_query(" SELECT * FROM person WHERE login="". preg_replace("/[^\\w_-]/","",$PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) . """); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm=\"Användarområde\""); header("HTTP/1.0 401 Unauthorized"); print("För att logga in på användarområde del av webbplatsen, måste du ange ditt användarnamn och lösenord."); exit(); ); $user_row = mysql_fetch_array($result);

På den första raden tas alla tecken utom bokstäver, siffror, bindestreck och understreck bort från inloggningen. Antalet rader som tas emot kontrolleras sedan och endast om det är en rad ges tillgång. I andra fall kommer användaren att se ett fönster i webbläsaren som uppmanar dig att ange inloggning och lösenord. Om användaren loggade in framgångsrikt har vi all information om honom i arrayen $user_row.

Naturligtvis har exemplet jag gav ett antal betydande brister. Skriv inte om det en-till-en för att inte bli offer för lösenordsgissningsförsök, eftersom
1. här finns inget skydd mot urval
2. om användartabellen är stor, när man gissar lösenordet, kommer en angripare sannolikt att överväldiga databasen

Och den sista metoden för idag är att lagra krypterad data i cookies.

Det finns ett skript för att logga in, resten innehåller kod som bara låter dig fortsätta handlingar i ett stängt område - om cookies upphör eller om han loggar ut därifrån måste du gå tillbaka till inloggningssidan.

Inmatningsskriptet kontrollerar inloggning och lösenord och utfärdar två cookies. I den första - inloggningen, för att omedelbart identifiera användaren (i databasen är inloggningsfältet naturligtvis unikt eller till och med nyckel). Den andra kakan innehåller en hash av inloggningstiden och lösenordet (för fullständig sekretess lägger jag till bokstaven "Y" på dessa rader - då är det nästan omöjligt att hitta hashen :).

Alla andra program innehåller kod som gör följande. Gör en begäran till databasen - väljer raden med mottagen inloggning. Från den här raden tar den "log_time"-fältet och lösenordet och gör en hash från dem, som beskrivits ovan. Jämför det med vad det fick, och om de matchar, utfärdar en ny hash-cookie, igen, från lösenordet, tiden och bokstaven "Y" och gör en fråga till databasen "UPDATE user SET log_time="..." WHERE login = "$cookie_login"".

If (isset($HTTP_COOKIE_VARS[$cookie_login]) && isset($HTTP_COOKIE_VARS[$cookie_code])) ( $login = $HTTP_COOKIE_VARS[$cookie_login]; $code = $HTTP_COOKIE_VARS[$cookie =mys_code");SELECT $lres. date_format(log_date,"%Y%m%d%H%i%s") som log_date1,pass,uid FROM user WHERE email="$login" AND log_date>"DATE_SUB(NU(),INTERVAL 15 MINUTE)"" ); if (!mysql_error() && @mysql_num_rows($result)==1) ( $log_time0 = time(); $log_time1 = date("YmdHis", $log_time0); $log_time2 = date("Y-m-d H:i :s", $log_time0); $current_user = mysql_fetch_array($result); if (md5($current_user["pass"].$current_user["log_date1"].$md5letter) == $code) ( mysql_query("UPPDATERING user SET log_date="$log_time2" WHERE uid=".$current_user["uid"]); setcookie($cookie_code, md5($current_user["pass"].$log_time1.$md5letter), time()+900, $site_path); $auth = true else unset($current_user);

Återigen finns det inget skydd här från val och attack på servern (förresten, här kan du skriva användarens IP-adress istället för bokstaven "Y" - så att till exempel en kontorsgranne inte kan ta en fil med en cookie och logga in från sin dator).

När jag postade det här numret förra gången sparkade de mig på plats och sa att ett sådant block kunde spåra ur servern.

Men först om rebound-blockering. Banaliteter, men ändå. Ett lösenord på tio tecken som består av latinska bokstäver och siffror betyder att det finns många alternativ. Om du gissar ett lösenord 1 000 000 gånger per sekund tar det flera tusen år. Men eftersom sådan gobbledygook är svår att komma ihåg, gör vi ofta lösenord av meningsfulla ord. För några år sedan visade det sig att de flesta lösenord går att gissa med hjälp av en ordbok på 10 000 ord. Vid ett tillfälle dök en mask (ett sådant virus) upp på nätverket, som klättrade på Unix-servrar, med hjälp av deras säkerhetshål och plockade upp lösenord för privilegierade användare med... Unix-systemets stavningsordbok. Det behövdes inte bära något!

Varje användare, tills han har angett rätt inloggning och lösenord, anses vara en ond hackare. Vad gör vi när användaren anger något felaktigt?

• glömska (för detta har anständiga webbplatser ett "glömt lösenord"-formulär för att skicka samma lösenord till e-postmeddelandet som angetts i systeminställningarna)
• bortskämd ("för jag bryr mig inte")
• välja ett lösenord med hjälp av en ordbok (sannolikheten för ett framgångsrikt val är hög, så du måste stänga den, särskilt om webbplatsen är av kommersiell karaktär)
• DoS-attack (för att inte överbelasta servern måste du minimera de åtgärder som skriptet kommer att utföra i det här fallet)

  Jag funderade länge på hur jag skulle kunna orsaka en överbelastning på servern om skyddsmekanismen är baserad på filer. Det visade sig vara enkelt (hur mycket det kommer att kosta är en annan fråga). Så låt oss säga att servern inte kommer att kunna hantera det om skriptet försöker öppna filer för att skriva 1000 gånger i sekunden och skriva data till dem. Eftersom efter 5 misslyckade försök att logga in, kommer användaren omedelbart att nekas åtkomst (utan att data skrivs till en fil), är det nödvändigt att hitta 200 unika IP-adresser, från vilka man kan kontakta fem gånger. Det är möjligt. Vi hänger en html-banner med fem taggar i bannerscrollern:

  

  Användaren gör omedelbart fem förfrågningar servern skriver till filen fem gånger (förresten, i vissa webbläsare kan ett fönster för inloggning och lösenord dyka upp). Du kan göra en HTML-sida med fem sådana bilder, och infoga själva sidan via en iframe på webbplatsen du besöker (via en iframe - så att referensfältet inte hittas. Det är osannolikt att supporttjänsten för en gratis hosting kommer att hantera sådana saker som att gräva igenom loggfiler på jakt efter hänvisningsadresser). Exemplen som jag gav är naturligtvis långsökta, men själva det faktum att man kan dra fördel av ett sådant fel i systemet har bevisats. Något liknande har förresten redan hänt.

  Men jag kommer fortfarande att ge den här metoden - jag skrev den förgäves, eller vad? Förresten, den kan användas utan större rädsla för ett begränsat antal adresser (till exempel för ett företags lokala nätverk) genom att placera en .htaccess-fil i katalogen med följande innehåll:

  Beställ neka, tillåt neka från alla tillåt från xxx.xxx.xxx

  Och här är programkoden:

  $errors = 0; $fn = "ignorera/". preg_replace("[^\d\.]", "", $REMOTE_ADDR. ".". $HTTP_FORWARDED_FOR); if (is_file($fn)) ( if (filectime($fn)< time()-3600) unlink($fn); else $errors = fread(fopen($fn, "r"), 2); }; if ($errors>5) ( print ("Åtkomsten är stängd. Vänligen kom tillbaka om en timme."); exit(); );

  // här upprättas anslutningen till databasservern. för att inte röra förgäves om användaren omedelbart blir "slagen".

  $result = mysql_query("SELECT * FROM user WHERE login="". preg_replace("/[^\w_\-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) . """); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm=\"hemligt område\""); header("HTTP/1.0 401 obehörig"); skriv ut ("Auktorisering krävs") ; fwrite(fopen($fn, "w"), ++$fel); $current_user = mysql_fetch_array($result); mysql_free_result($result);

  Det är dock synd att arbeta med filer om det finns en databas. Skämt. För misslyckade auktoriseringar, skapa en tabell:

  CREATE TABLE unauth (användarnamn VARCHAR(64) NOT NULL, pass VARCHAR(64) NOT NULL, ip VARCHAR(255), inloggningstidsstämpel)

  Och istället för att komma åt filer arbetar vi med databasen.

  $errors = @mysql_result(mysql_query("SELECT count(användarnamn) som falskt FROM unauth WHERE inloggningstid>DATE_SUB(NU(),INTERVALL 1 TIMME) OCH ip="$REMOTE_ADDR""),0); if (mysql_error()) die(mysql_error()); if ($errors>5) ( print ("Åtkomsten är stängd. Vänligen kom tillbaka om en timme."); exit(); ); $result = mysql_query("SELECT * FROM user WHERE login="". preg_replace("/[^\w_\-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) . """); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm=\"hemligt område\""); header("HTTP/1.0 401 obehörig"); skriv ut ("Auktorisering krävs") ; mysql_query("INSERT INTO unauth (användarnamn, pass, ip) VALUES ("$PHP_AUTH_USER", "$PHP_AUTH_PW", "$REMOTE_ADDR $HTTP_X_FORWARDED_FOR")"); $current_user = mysql_fetch_array($result); mysql_free_result($result);

  Om man ska lagra gamla register för statistik eller inte är ett affärsbeslut. Om något kan de raderas genom att utföra följande begäran innan auktorisering:

  DELETE FROM unauth WHERE logintimeDATE_SUB(NOW(), INTERVAL 30 MINUTE)"); if (!mysql_error() && @mysql_num_rows($login_result)==1) ( /* Få en tabellrad och skapa en hash av de obligatoriska fälten. */ $ current_user = mysql_fetch_array($login_result); $hash_to_check = md5($current_user["passwd"]. "Y - så att ingen gissar." $current_user if ($hash_to_check == $HTTP_COOKIE]_VARS[$CO); ) ( $current_time = time(); /* Uppdatera det senaste inloggningsfältet och utfärda en ny cookie */ mysql_query("UPDATE user SET last_log="". date("Y-m-d H:i:s", $current_time). " " WHERE login=". $login""); setcookie($COOKIE_HASH_NAME, md5("Y-m-d H:i:s", $current_time). "Y - så att ingen gissar." $current_user["passwd" ]), $current_time + 1800 , $COOKIE_PATH ) else ( /* Om hashen inte stämmer omdirigeras användaren till inloggningssidan. */ header ("Plats: /login.php"); exit; ) elseif (!mysql_error() && @mysql_num_rows ($log_result)!=1) ( header("Plats: /login.php"); utgång;

  ) else print (mysql_error()); Självklart"Y - så att ingen gissar"

  Förresten, om IP-adressen. Det är bättre att kontrollera det, men inte hela adressen, utan bara de två första (för ip som börjar med ett nummer mindre än 127) eller tre (respektive fler än 127) siffror i adressen. Detta kommer att rädda användare av en dålig och avbruten uppringd uppringning från att behöva logga in igen efter att anslutningen har förlorats, och kommer samtidigt inte att tillåta en angripare som stal kakan att logga in. Naturligtvis kommer han inte att kunna ringa tillbaka och logga in via en annan leverantör - pooladressen är inte densamma, men detta är inte vårt problem ("i det här vädret stannar de hemma"). Inte heller stöld av lösenord inom företaget är vårt problem. Vi skyddade från nyfikna kamrater och analfabeter, men vi kan inte göra något mot trojaner och sniffers som kan installeras på offret.

  Det är där "klockorna och visselpiporna" slutar. Skyddet kan inte göras mer tillförlitligt. Ingen kommer att gå in i cookie-filen för hashen och hämta den. Det skulle vara lättare att placera en sniffer mellan användaren och webbgränssnittet och använda den för att hitta lösenordet. Du kan installera en trojan som kommer ihåg allt som användaren skrev in på tangentbordet, men detta är inte längre vårt problem. För att skydda mot kanalavlyssning måste du använda SSL-anslutningar eller datakryptering.

  Lösenord för sidan. Del 5. Sessioner

  Varför skrev jag en anteckning om cookies? "Jag förstår inte varför man skriver om cookies när PHP har sessioner?!" Sedan, så att läsarna inte har en platt bild framför ögonen. PHP version 4 är inte tillgänglig överallt ännu, och version 3 stöds inte. Dessutom är sessioner inte så nödvändiga överallt - med sällsynta undantag kontrollerar auktoriseringsalgoritmen riktigheten av inloggningen/lösenordet och riktigheten av sessionsdata, och returnerar sedan antingen klienten till inloggningssidan eller tar en array (eller objekt) ) med data om användaren.

  Fall då arbete i sessioner är nödvändigt är inte så vanliga. Till exempel, i mitt spel "Monopolist" började jag genast använda sessioner, eftersom användaren kan spela flera spel och samma sida i samma session kan innehålla olika data. Där är det bättre att lagra data för ett av spelen där användaren deltar i en session och skapa en sida för att växla mellan spel.

  Generellt sett säger jag inte att sessioner inte ska användas. Det är nödvändigt, men allt har sin plats. Jag återkommer till frågan om tillämpligheten av tre auktoriseringsmetoder - genom 401-huvudet ("riket"), cookies eller sessioner - senare. Låt oss nu prata om sessioner.

  Sessioner i PHP är egentligen inte en auktoriseringsmetod (konceptet i sig är felaktigt, men i forumen frågar de exakt "hur man auktoriserar en användare genom sessioner?"). Användarsessionsmekanismen inbyggd i PHP identifierar endast dessa användares auktorisering är, återigen, ditt skripts arbete.

  Jag kommer inte att berätta mycket om mekanismen för sessioner - det har redan sagts. I sin enklaste form (eller snarare, i sin vanligaste form) fungerar denna mekanism så här: systemet håller en sessionsfil på servern som innehåller dess variabler. När du startar en session får användaren en unik identifierare (vanligtvis genom en cookie), och när han går in på andra sidor skickar han den. När du startar sessionsmekanismen i ditt skript kontrollerar php-hanteraren om en fil som motsvarar den inkommande sessionsidentifieraren finns - om den finns kommer skriptet att kunna läsa data från filen, om inte kommer en ny session att startas och filen kommer att skapas. Naturligtvis är namnet på denna variabel definierat i php-inställningarna.

  Nu om vilka funktioner vi använder.

  session_start() . Startar själva sessionsmekanismen. Användaren måste ha en variabel och en motsvarande fil. Om det inte finns någon fil skapas den och sessionen startas från början. Om det varken finns en fil eller en variabel, så genereras en variabel (till exempel skickas en rubrik med en cookie) och filen skapas.

  session_register(namn1, namn2, namn3...) . Indikation på vilka variabler som ska komma ihåg i filen i slutet av skriptet. Efter att användaren navigerat till en annan sida kan sessionsmekanismen startas, och efter att ha anropat denna funktion kommer variablerna att vara tillgängliga.

  session_destroy() . Tar bort sessionsdatafilen (när du använder cookies måste du radera dem manuellt genom att ställa in en tom cookie: "setcookie(session_name())" ).

  session_set_cookie_params(liv, sökväg, domän) . Ställa in cookieparametrar med en sessionsidentifierare (som standard sätts cookien till roten på servern och i 0 sekunder - tills webbläsaren stängs).

  Det var allt tills vidare. Det kommer att finnas separata nummer om sessionerna i detalj. För nu kommer jag att beskriva mekanismen för auktorisering och användaridentifiering med hjälp av sessioner.

  Så vi har tre filer - inloggning, verifiering (auth) och utgång (utloggning).

  // klipp ut alla oönskade tecken $login = preg_replace("/[^\w_\.\-]/", "", $HTTP_POST_VARS["login"]); $pass = trim($HTTP_POST_VARS["pass"]); // kontrollera variabler if (strlen($login)==0 || strlen($pass)==0) $error = "Ange ditt användarnamn och lösenord"; else ( // kontrollerar inloggning och lösenord $user_result = mysql_query("SELECT * FROM user WHERE login="$login" AND pass="". md5($pass). """); /* om ett fel inträffade i databas (till exempel, användaren infogade en lång variabel i sessionen, som databasen inte ville smälta) eller mer än en rad visade sig, sparkar vi användaren */ if (mysql_error()) die(mysql_error()) ; elseif (@mysql_num_rows($user_result) != 1) $error = "Ogiltigt användarnamn eller lösenord." (1800, "/"); session_start() ; // kom ihåg användarinformationen session_register("user"); ($HTTP_POST_VARS["return"]) "); else header("Plats: /"); exit(); ); ); /* här är användaren inte längre behörig, men kan skicka en cookie från en stängd session. låt oss städa upp det. */ if (isset($HTTP_COOKIE_VARS)) setcookie(session_name()); // nästa ritar vi formen, detta är inte intressant.

  Detta skript är både en hanterare och ett datainmatningsformulär. När den får inloggning och lösenord bearbetar den dem och, om de är korrekta, slutar fungera och skickar användaren till önskad sida. Om uppgifterna är felaktiga eller saknas, ritar formuläret.

  /* döda användarvariabeln så att efter att ha ritat formuläret är det omöjligt att skicka data i en postförfrågan. */ unset($användare); // "session error" flagga - om den är aktiverad kommer arbetet att sluta. $session_error = false; // om det inte finns någon cookie med sessions-ID, höj flaggan om (!isset($HTTP_COOKIE_VARS)) $session_error = true; // om det finns, starta sessionsmekanismen och registrera $user-variabeln. else ( session_start(); session_register("användare"); /* om det av en slump inte finns någon inloggning och lösenord i arrayen, stannar arbetet också ("vi vet ingenting, vi gav dem till dig") */ if (!isset($user[" login"]) || !isset($user["pass"])) $session_error = true ); /* om användaren hittills lyckats undvika fel, görs en kontroll genom databasen på samma sätt som vid ingången. */ if (!$session_error) ( $check_result = mysql_query("SELECT uid FROM user WHERE login="($user)" AND pass="($user)""); if (mysql_error() || @mysql_num_rows( $user_result) != 1) $session_error = true ); // om det fanns något fel, sedan if ($session_error) ( // förstör sessionsdata session_destroy(); // förstör cookien om det fanns en if (!isset($HTTP_COOKIE_VARS)) setcookie(session_name()," " ,"/"); /* skicka användaren att logga in, med möjligheten att återgå till den begärda adressen */ header("Plats: /login.php?return=$REQUEST_URI"); // sluta fungera exit() ; mysql_free_result($check_result);

  Användaren är kontrollerad och i $user-arrayen - all data om honom kan du till exempel hälsa på honom med hans förnamn och patronym:

  If(isset($HTTP_COOKIE_VARS)) ( // starta sessionsmekanismen session_start(); // radera filen session_destroy(); // ta bort cookien setcookie(session_name()); ); // avsluta sidhuvudet("Plats: /login.php");

  Ett par anteckningar: den del som skyddas av ett lösenord i det här exemplet är hela servern (till exempel service.firm.ru), för att stänga katalogen måste du korrigera sökvägarna. Session_name() används istället för PHPSESSID så att identifierarens namn kan ändras fritt. Förresten, på en fysisk server kan du skapa olika namn för sessionsidentifierare - lägg bara .htaccess-filen i den nödvändiga delen med raden php_value session.name "ABRACADABRA" .

  
  
  
  

  Om du har några andra frågor eller något är oklart - välkommen till oss

  Sätt ett lösenord på sidan

  Den här artikeln låtsas inte vara några uppenbarelser alla dessa saker är ganska uppenbara och allmänt kända. Men efter att nyligen ha fått flera frågor om att begränsa åtkomsten till webbsidor bestämde jag mig för att sammanföra svaren på dem.

  Så vår uppgift är att ställa in ett lösenord för att komma åt en viss sida. Låt oss börja med den mest primitiva metoden, så att säga, för skydd - några rader JavaScript

  Var pass = prompt("Ange lösenordet:", ""); if (pass == null) window.location = "bad.html"; else if (pass.toLowerCase() == "lösenord") window.location = "ok.html"; annars window.location = "bad..js"> ändrar ingenting i grunden.

  På en högre nivå finns ett liknande system implementerat i Java.

  Nedan finns den förenklade källkoden.

  Importera java.applet.*; importera java.awt.*; importera java.net.*; public class Password extends Applet ( TextField login, lösenord; String Login = "login"; String Password = "Password"; public Password() ( ) public void init() ( Panel panel = new Panel(); panel.setLayout(new GridLayout(2,2)); login = new TextField(20)); new Button("Ok")); public boolean action(Event evt, Object obj) ( if(evt.target instansof Button) (String s; if(login.getText().equals(Login) && password.getText() .equals(Password)) ( s = "http://www.webclub.ru/materials/ pagepsw/ok. html"; ) else ( s = "http://www.webclub.ru/materials/pagepsw/bad .html"; ) försök ( getAppletContext().showDocument (ny(a) URL(er)); ) catch(Undantag e) ( password.setText(e.toString()); ) return true; return false;

  Genom att inkludera denna applet på en sida kan du få något sånt här:

  Lösenordskoll

  Det kan göras smartare, skapa en separat sida för varje användare, tvinga den att läsa data från en fil osv. Den grundläggande nackdelen är att när en person väl har landat på sidan han letar efter kan ingen hindra honom från att komma ihåg denna URL, så detta är ett engångsverktyg. Naturligtvis kan du gömma sidan inuti en ram så att URL:en inte visas i adressfältet, men du förstår vem detta skydd kommer från. Återigen går appleten helt till kunden och är i princip helt tillgänglig för forskning.

  Lösningen baserad på användningen av CGI har inte den sista nackdelen. Ett enkelt Perl-skript ser ut ungefär så här:

  #!/usr/bin/perl använd CGI qw(:standard); $query = ny CGI; $ok = "ok.html"; $address = "bad.html"; $login = "logga in"; $password = "lösenord"; $l = $query->param("login"); $p = $query->param("lösenord"); if(($p eq $password) && ($l eq $login)) ( $address = $ok; ) skriv ut $query->redirect($address);

  Användningsexempel:

  Lösenordskoll

  För att hantera den första nackdelen kan du dynamiskt generera en ny sida baserad på den som är gömd någonstans inuti, utan att ge ut URL:en.

  Ändrad kod:

  #!/usr/bin/perl använd CGI qw(:standard); $query = ny CGI; $ok = "ok.html"; $address = "bad.html"; $docroot = $ENV("DOCUMENT_ROOT"); $localpath = "/materials/pagepsw/"; $login = "logga in"; $password = "lösenord"; $l = $query->param("login"); $p = $query->param("lösenord"); if(($p eq $password) && ($l eq $login)) ( $address = $ok; ) skriv ut $query->header(); open(FL, $docroot.$localpath.$adress); while() ( # Här kan du också ändra html-koden i farten # Varför? Tja, man vet aldrig... :) print $_; )stäng(FL);

  Användningsexempel:

  Lösenordskoll

  Som du kan se visas inte längre filens URL, fast på bekostnad av SSI, om något liknande fanns (dock kan detta fångas upp under utmatning och bearbetas manuellt). Men även här kvarstår den teoretiska möjligheten att gissa webbadressen, och vi får inte glömma att alla möjliga bilder som ingår på sidorna kan göra en otjänst - när man använder relativa sökvägar, förstås.

  Slutligen, det mest pålitliga sättet att ställa in ett åtkomstlösenord är att använda serververktyg - det är inte för inte som folk gjorde dem, trots allt. Jag kommer att fokusera på två - Apache som den mest populära och IIS som också populär :)

  Med IIS är allt ganska enkelt - skyddet utförs med NTFS, vilket naturligtvis begränsar kapaciteten för icke-serveradministratörer något. Tanken är följande: användaren IUSR_xxxx, under vars konto alla webbplatsbesökare arbetar som standard, nekas åtkomst till önskad fil/katalog. Därefter kommer endast de användare för vilka detta uttryckligen anges i Egenskaper->Säkerhet att ha tillgång till dessa filer. Det är tydligt att det är mycket bekvämare att kombinera dem i grupper. Det finns ett par subtiliteter här. För det första måste de angivna användarna ges inloggningsrättigheten lokalt (Policyer->Användarrättigheter i Användarhanteraren. För det andra, om du inte väljer WWW-tjänsten Grundläggande autentisering (Rensa text) i WWW-inställningarna, kommer endast Internet Explorer-användare att vara det. tillåtet i "A.

  I Apache görs allt lite annorlunda. Skydd är inställt på katalognivå. Motsvarande direktiv kan placeras både i den allmänna konfigurationsfilen (i avsnittet) och i .htaccess-filerna. Uppsättningen av direktiv är i båda fallen densamma, och för de flesta som hyr utrymme för en webbplats/sida på någon annans server är den andra metoden mycket mer relevant. Så du skapar en .htaccess-fil i katalogen som du planerar att begränsa åtkomst till och infogar sedan följande direktiv i den (jag kommer att lista de viktigaste):

  AuthType typ av kontroll– Basic brukar användas.

  AuthName namn- anger namnet på området där användarnamn och lösenord är giltiga. Detta är samma namn som webbläsaren visar i lösenordsdialogrutan. Genom att ställa in ett sådant namn för olika kataloger kan du spara användarna tiden för att ange ett extra lösenord.

  AuthGroupFile namn- anger namnet på filen där namnen på grupper och deras medlemmar är lagrade. Dess format:
  grupp1: medlem1 medlem2 ...
  grupp2: medlem3 medlem4 ...

  AuthUserFile namn- anger namnet på filen med lösenord. För att generera det måste du i stort sett använda verktyget htpasswd från Apache-distributionen. Men åtminstone för vissa versioner av servern är detta format så här:
  användare1: passwordhash1
  användare 2: passwordhash2

  Passwordhash kan enkelt erhållas med den vanliga Perl-funktionen:
  $hash=krypt($pass,$salt);
  där $pass är lösenordet, är $salt en tvåteckensträng som är involverad i att generera hashen.

  Så det är fullt möjligt att automatisera processen att lägga till nya användare, ändra lösenord via html-formulär, etc.

  kräver användare användare1 användare2 och kräver grupp användare1 användare2 låter dig ange vilka användare och grupper som ska ha tillgång till en given katalog.

  kräver giltig-användare ger åtkomst till alla användare som anges i systemlösenordsfilen.

  ... , där metod i definierar en HTTP-metod. Till exempel begränsar det användningen av kapslade direktiv till fall av användning av metoderna GET och POST (vanligtvis är detta mer än tillräckligt). Direktiv kan kapslas: kräva, beställa, tillåta och neka.

  Ytterligare ett par användbara direktiv är neka och tillåta - neka respektive tillåta åtkomst. Använd något så här:
  förneka från alla
  tillåta från 192.168

  Som standard exekveras alla neka först, sedan tillåts alla, så tillåt från alla ger åtkomst till alla användare, oavsett avslag. Ordningen kan ändras med orderdirektivet: order tillåter, neka.

  deny from all går bra med den andra metoden att skydda sidor via CGI, det är detta direktiv som är bäst för att täcka alla slags lösenord för gästböcker, etc.

  Förresten, här i förbigående demonstreras oberoende felhantering: i detta fall kod 403, Förbjudet. De älskade 404, Not Found och 401, Unauthorized behandlas på liknande sätt. För att göra detta, lägg bara till ErrorDocument-direktivet till .htaccess URL-kod:
  ErrorDocument 404 /cgi-bin/bad.pl
  ErrorDocument 403 /cgi-bin/badaccess.pl
  ErrorDocument 401 /cgi-bin/badaccess.pl

  Allt skriptet gör är att generera ett felmeddelande med hjälp av miljövariabeln REQUEST_URI, så du kan bara peka på någon lämplig sida istället.

  För det sista exemplet använder vi en .htaccess-fil med följande innehåll:

  AuthType Basic AuthName Test AuthGroupFile /.../pagepsw/deny/tgroup AuthUserFile /.../pagepsw/deny/tuser kräver grupptest

  Det finns bara en rad i tgroup-filen - test: inloggningstest, i användarfilen - krypterade lösenord för inloggning (lösenord) och test (test). Observera att när du går in på den här sidan igen förstår webbläsaren att den just har nått det här området och stör inte användaren med en onödig begäran om lösenord.

  Detta är i korthet den minsta mängd information som krävs för att skydda webbsidor. Som praxis visar bör du mer eller mindre bara lita på lösningar baserade på de verktyg som servern tillhandahåller (och sedan tills ett annat hål upptäcks i servern), så om möjligt är det bättre att välja dem.

  
  

  Ett av informationssäkerhetens huvudaxiom säger att "bekvämligheten i ett system är omvänt proportionell mot dess säkerhet." Detta innebär att när man väljer ett säkerhetssystem är det nödvändigt att hitta den optimala balansen mellan säkerhetens komplexitet och användarupplevelsens bekvämlighet.

  
  

  Å andra sidan kräver utveckling och implementering av skydd en viss ansträngning och pengar. Därför är det nödvändigt att ta ett rimligt tillvägagångssätt för att utforma skydd. Enkelt uttryckt finns det inget behov av att skapa ett komplext och dyrt säkerhetssystem om inget värdefullt lagras på webbplatsen. Inte en enda angripare kommer att försöka bryta din hemsida, visitkortswebbplatsen för ett litet företag eller webbplatsen för ett dagis.

  
  

  I föregående lektion tittade vi på auktorisering med hjälp av en webbserver (grundläggande auktorisering). Detta är förmodligen det enklaste och säkraste sättet att begränsa tillgången till resurser. Att upprätthålla en sådan mekanism är dock ganska arbetskrävande, särskilt med ett stort antal användare med olika rättigheter. Dessutom tillåter inte alla servrar HTTP-autentisering.

  
  

  Ett mer populärt alternativ är lösenordsskydd. Dess betydelse är att servern lagrar listor över användare och deras motsvarande inloggningar, lösenord och åtkomsträttigheter. När användaren går in på sidan för första gången anger användaren ett inloggningsnamn/lösenord och får tillgång till resurserna. Servern "kommer ihåg" användaren och ber inte om ett lösenord förrän nästa session öppnas (omstart av webbläsaren).

  Organisationen av lösenordsskydd faller helt på programmerarens axlar. Utvecklaren måste säkerställa säkerheten för att lagra användarlistor, kontrollera inloggningar/lösenord, spara säkerhetssammanhang och återanvända dem. Säkerhetskontexten här förstås som en uppsättning parametrar som unikt identifierar användaren (det här är åtminstone en inloggning, lösenord och sessionsidentifierare).

  Tänk på ett exempel på att implementera det enklaste lösenordsskyddet. Låt oss skapa en fil logon.php

  När du klickar på "login"-knappen kommer formulärdata att skickas till servern, där skriptet kommer att kontrollera det angivna inloggningsnamnet och lösenordet och om de är lika med "admin" respektive "megaPass", kommer det att visa en meddelande om att inloggning är tillåten. Om inloggningen eller lösenordet är felaktigt kommer användaren att se ett varningsmeddelande.

  Den första nackdelen med detta skript: dataöverföring med GET-metoden. När du använder denna metod överförs data direkt i adressen och är därför synlig även för blotta ögat. Om du till exempel har angett rätt användarnamn och lösenord kommer du att se i adressfältet

  Http://localhost/logon.php?login=admin&passwd=megaPass

  Den andra nackdelen: användarnamn och lösenord hårdkodas direkt i koden. Detta innebär att för att lägga till nya användare måste du hela tiden ändra filkoden. Föreställ dig bara hur stor filen blir om du har minst tusen registrerade användare på din webbplats... Användarlistor lagras bäst i en separat fil, eller ännu bättre, i en databas, eftersom... Det är mycket lättare för en angripare att stjäla en fil än att extrahera något från en databas.

  Den tredje nackdelen: användarens inloggningsresultat kommer inte ihåg, dvs. Uppdatera bara sidan så kommer du att bli ombedd att ange ditt lösenord igen.

  Så låt oss titta på sätt att eliminera dessa brister.

  Det enklaste sättet att dölja överförda data är att använda POST-överföringsmetoden. I det här fallet kommer webbläsaren själv (dold för användaren) att överföra all nödvändig data till servern och den kan bara fångas upp av speciella program från arsenalen av IT-specialister, programmerare eller hackare.

  Som nämnts ovan måste användarlistor lagras separat. Låt oss skapa en tabell i testdatabasen:

  SKAPA TABELL `smplusers` (
  `user_id` int(11) NOT NULL auto_increment,
  `användarnamn` varchar(50) NOT NULL,
  `user_login` varchar(50) NOT NULL,
  `user_password` varchar(50) NOT NULL,
  `reg_date` datetime NOT NULL,
  PRIMÄRNYCKEL (`user_id`)
  )

  och lägg till flera användarposter till den:

  SÄTT IN I smplAnvändare
  (user_name, user_login, user_password, reg_date)
  värden
  ("Ivanov I.I.", "ivanov-i-i", "pass1", NOW()),
  ("Petrov P.P.", "petrovich", "pass2", NOW()),
  ("Sidorov S.S.", "sidorov", "pass3", NOW())
  

  Observera att INSERT-operatorn tillåter att flera poster läggs till i tabellen samtidigt, och att data listas i block separerade med kommatecken.

  Låt oss nu ändra logon.php så att användarnamnet och lösenordet kontrolleras korrekt direkt i databasen:

  
  
  
  
  
  
  

  Nu sänds inloggning och lösenord i hemlighet, och det är mycket enkelt att ändra inloggningsuppgifterna genom att redigera tabellen i databasen. Det sista steget återstår - att lära servern att komma ihåg registreringen. Det enklaste sättet att göra detta är att använda sessionsmekanismen. Låt oss göra de nödvändiga ändringarna:

  
  
  ...

  Servern kommer nu ihåg varje användare som lyckades logga in och kommer att visa ett välkomstmeddelande nästa gång sidan uppdateras.

  Det här skriptet är bara ett exempel på att organisera lösenordsskydd, om än ett fullt fungerande sådant. Du kan förvandla det till ett praktiskt taget värdefullt exempel genom att lägga till indataverifiering, krypteringsfunktioner, lösenordsåterställning, sessionsslut, etc.