MAIMONIDES:
Sweet32: Birthday attacks on 64-bit block ciphers in TLS
Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN
https://sweet32.info/
OpenSSL has moved 3DES ciphersuites from the HIGH category to MEDIUM in the 1.0.1 and 1.0.2 branches, and will disable it by default in the upcoming 1.1.0 release.

*shrug*
Kde máš nějaký argumenty pro tvrzení, že 3des2 nebo 3des3 je "nahraně".
Cítění, myšlení nebo vlastní dlouholetá odbornost, to je irelevantní. Tvrdý data a konkrétní útoky.

MAIMONIDES: Zrovna 3DES uz je na hrane bezpecnosti, ale AES128 by tam mohlo byt. Treba u TLS neprinasi AES256 zadnou vyssi bezpecnost, jen vyssi vypocetni naroky.

PJOTRIK: Knihovna bez aes128 je pro děti, co si hrajou na písku. normální lidi komunikují s okolním světem existujícíma protokolama a tam je zpravidla aes128 nebo 3des2 a oboje je zcela bezpečný a zůstane to tak dlouho bezpečný jako aes256.

MORMEGIL: username se hashuje asi kvůli zmatení potenciálního útočníka, je to tak historicky, co ten framework vzniknul (cca rok 2007). Protože ale dělám migraci na .NET 4.6.2 a Visual Studio 2017, můžu si dovolit udělat určitý změny, který nebudou zpětně kompativilní a došel jsem až k řešení ukládání hesel
MORMEGIL: jo ajo
MORIARTY: Valášek o tom měl přednášku i na nedávním MSFestu, ale byl jsem nakonec na jiný
O nějaký extra citlivý data nejde, a hesla jsou většinou typu "lopata", "kobliha", "1A23d65", protože obsluhy ovládající výrobní technolologie nemají zrovna velké znalosti ohledně počítačů a IT

Každopádně díky, použiju Rfc2898DeriveBytes

MORMEGIL: Já čet: Chybí vám tam stůl. Úplně zmatenej. :)

TOOMIX: Teď jsem zrovna u Valáška na školení a ten doporučuje PBKDF2 s aspoň 10 tisícemi iteracemi. Takže jak píše MORMEGIL: https://msdn.microsoft.com/...library/system.security.cryptography.rfc2898derivebytes(v=vs.110).aspx
MD5 je už hodně mimo, ale taky ho v některých starých projektech používáme :/

Měl bych otázku ohledně šifrování hesel...

v současné době to máme v našem frameworku tak, že se vezme login, heslo, pro každý zvlášť se udělá následující funkcí MD5 hash, odstraní se pomlčky a spolu se to uloží do DB oddělené pomocí rovnítka - |.

public static string GetMD5Hash(string aValue)
        {
            MD5 md5Provider = MD5CryptoServiceProvider.Create();
            Byte[] valueBytes = Encoding.Unicode.GetBytes(aValue);
            Byte[] hashBytes = md5Provider.ComputeHash(valueBytes);
            return (BitConverter.ToString(hashBytes)).Replace(MD5_HASH_DELIMITER, String.Empty);
        }

Co byste doporučili jako náhradu za MD5? Providerů v System.Security.Cryptography je mraky, AES, SHA256 atd.
Tu logiku se spojenými hashi bych asi zachoval, ale MD5 jaksi není hodné roku 2016. Díky

MORMEGIL: jo taaak...

VIRTUALVOID: Tak on píše, že je chce _stáhnout_, ne zobrazit.

PEPSIN: tak ja neviem, ale byt prehliadac tak ti octet-stream nezobrazim ako obrazok :) skus mu posielat to co naozaj mas... minimalne z toho nazvu suboru sa da mime-type zistit.

kazdopadne ak sa naozaj jedna o mvc app, a vracias to von z controllera, tak by som rozmyslal o niecom takomto:

public ActionResult Metoda()
{
 ...
  return File(ms.GetStream(), "image/jpeg");
}

VIRTUALVOID: VIRTUALVOID: Tak headery vypadaji tak nejak takhle

Cache-Control: private
Content-Length: {delkaSouboru}
Content-Type: application/octet-stream
Content-Location: traslasierra_16to10.jpg
Content-Disposition: attachment; filename*=UTF-8''{jmenoSouboru}
Content-Transfer-Encoding: binary

VIRTUALVOID: No to je mozny, ale v tom pripade mi osvetli jak je to dobre. (a proc to pro jine prohlizece funguje a pro IE jen obcas)


VIRTUALVOID: hmm mrknu, ten tam skutecne nejspis neji (je tam jen content-disposition attachment... a par dalsich, ale tenhle ne)

imho to s tym streamom nedelas dobre jaromire