aaaccc

Statistika

Pridružen/a:
16 okt 2014, 11:23
Zadnjič aktiven:
Prispevki:
Teme:
2 | Vse teme
42
21
0
#10

http://www.fakenamegenerator.com/



btc spuščen skozi par mixerjev (ali pa kupljen za gotovino) ter firma ki ne sprasuje prevec je precej preprosta zadeva, long term opsec pa precej večji problem


všeč(0) ni všeč(0) spam(0)
#4

kot omenjeno zgoraj, najlažje je če imaš tukaj odprt sp in invoice-as firmo v US kolikor pač rabiš


všeč(0) ni všeč(0) spam(0)
#14

suprpp:

@spicey: Hvala za skrb. :)



Stanje v našem sistemu je bilo do včeraj sicer sledeče:

- gesla in ostali podatki v bazi so v vsakem primeru že zakodirani, tako da je sama podatkovna baza praktično neuporabna brez PHP datotek;

- pri nas je bilo geslo vidno samo preko "salt" ključa oz. se preko le-tega odkodira, da je lahko sploh vidno;

- gesla torej v bazi niso bila v plaintext obliki.




Se opravičujem za malo offtopica ampak tole je pač treba omenit...



No, da razjasnimo par stvari.

Ker se očitno gesla dekodirajo pomeni da jih ne shranjujete v obliki hashov. salt o katerem ti govoriš je dejansko ključ za kerkoli simetričen kripto ste že ali pa še uporabljate.



Neglede na način hrambe plaintext gesla pač nikoli ne pošlješ uporabniku nazaj, kvečjem resetiraš in posreduješ po vnaprej znanem kanalu link za zamenjavo. Pri uporabi hashiranja so gesla v nereverzibilni obliki (lahko samo primerjaš hash-a, ne pa inputa(plaintext geslo) ki sta le te hashe dala). Salt se uporablja kot dodatni random input skupaj z originalnim plaintext geslom zato da se oteži uporabo dictionary napadov na hashe.



Point tega je da nobena implementacija v kateri imate vi vpogled v plaintext gesla strank na kakršn koli način ni varna.



http://www.securityinnovationeurope.com/blog/whats-the-difference-between-hashing-and-encrypting


všeč(2) ni všeč(0) spam(0)
#5

dh5114:

Super novica! Še en razlog več, da "zaradi svoje varnosti" uporabljaš closed-source zadevo, ki laufa direkt iz tvojega compa in jo "daje zastonj" ena največjih firm na svetu...



What could go wrong?






chrome gor al dol, izkoreninjanje nešifriranega prometa je odličen korak v pravo smer


všeč(1) ni všeč(0) spam(0)
#6

Zakaj ste dovolili, da je prišlo do napada?

Varnost jemljemo zelo resno. V podjetju imamo vpeljana pravila in postopke z namenom zagotavljati čim višjo stopnjo varnosti.




vir: http://www.domovanje-status.si/domovanje/



Postopke kot so zunanji pentesti/security auditi/pregledi kode?




ucimzar:




phpseo:

Če prav razmem so bila gesla shranjena v SHA-1 nesoljeni obliki.




Da, gesla so bila shranjena v nesoljeni obliki.




Uporaba unsalted gesel z sha1 je skoraj diametralno nasprotje jemanje varnosti resno


všeč(8) ni všeč(0) spam(0)
#

https://www.humblebundle.com/books/start-your-own-tech-company-book-bundle


všeč(0) ni všeč(0) spam(0)
#6

glede na povpraševanje po po front end developerjih s tremi leti izkušenj res nebi smel imet problema dobit nek biznis kje, ali projektno ali long term sodelovanje s kakšno firmo


všeč(3) ni všeč(0) spam(0)
#7

100% uptime-a ti nebo nikoli nihče ponudil ker je zadeva nesmiselna (in grozno veliko stane, predstavlja omejitve itd), hkrati je pa zanesljivost npr. internetnih ponudnikov tvojih strank precej nižja.



To je najlažje reševat na aplikacijskem nivoju spreadano čez več providerjev ali vsaj več AZ-jev na aws naprimer.



Sicer pa imaš sistemske integratorje pri nas ki ti ponujajo svoje cloud rešitve kjer ti bodo sestavili ponudbo s precej dobrim SLA-jem (ki te bo tudi precej stal), ampak bo pa verjetno bolj zanesljivo kot večina(vsi?) hosting ponudniki po sloveniji ki imajo (vsaj kar sem videl do sedaj) precej slabšo/manj redundančno glede na naravo biznisa


všeč(1) ni všeč(0) spam(0)
#43

@rodica7 procesor je zadnja stvar ki te tu bremza, daj še 4gb rama v mašino če lahko predvsem pa kot je nas-t1 rekel ssd obvezno pa bi ti lahko ta laptop še služil nekaj časa


všeč(0) ni všeč(0) spam(0)