start	end	text
2470	5710	Good afternoon, good evening, or even good morning,
5710	10170	depending on which part of the world you are listening to this talk from.
10410	11770	And no, it does not get old.
11770	15730	I still want to give a huge shout-out to the CryptoVillage organizing community
15730	19670	for making this virtual con happen for us.
21010	24470	Welcome to the second talk of the day from my side.
25270	27610	In this talk, I'm going to touch base upon
27610	31670	how to store sensitive information securely
31670	36190	so that we can safeguard it reasonably well
36190	39970	against any kinds of offline cracking attempts.
40270	43550	Before we go ahead, I'd like to introduce myself.
43550	44990	I'm Manasi Sheth.
44990	47190	I work as a security researcher
47190	51810	at a leading static analysis company called Veracode.
52710	56250	My primary responsibility here is to be on top
56250	59770	of the latest and greatest happenings in the security field,
59770	63470	more specifically in the application security domain,
63470	69330	and transfer that knowledge to make sure our customers are safe.
70330	72310	I'm a huge crypto enthusiast.
72310	77910	I have spent a lot of time, or actually a reasonable amount of time,
77910	83350	understanding different base crypto blocks.
84350	90130	Its practical implementations, how it can be used in the real world.
90170	92870	I understand a lot of anti-patterns.
92870	97230	I've spent a lot of time looking at different crypto implementations
97230	99350	across programming languages,
99350	103130	and I try to translate all this expertise
103130	107010	into making sure our customers' codebases are safe
107010	110730	and to help pick up any anti-patterns.
113510	115830	Recently, I got thinking,
115830	120270	why are we seeing so many data breaches in the first place?
120910	122230	Eventually, I realized,
122230	126250	okay, this is going to be a matter of when rather than if.
126250	129750	So, what can we do to protect this information
129750	131570	once it is already breached,
131870	134510	mainly from any kind of offline cracking?
134510	137690	How can we make the information cracking process
137690	141150	very, very expensive that it is almost useless?
141150	143110	So, in that quest,
143110	146430	first place I'll definitely go for that matter
146430	148870	of which first thing comes to anyone's mind
148870	151910	would be Troy Hunt's most organized,
151910	156870	most informative site about this called Have I Been Pwned.
158170	162170	In this site, he keeps a database of all the breaches
162170	164930	which has happened in probably last decade
165710	169750	and gives out information about what might have happened,
169750	174150	what has happened, and all those kind of neat stuff.
174610	178630	So, instead of putting a big slide of shame kind of thing,
178630	181670	like who got hacked and what were the reasons and stuff,
181670	186310	what I tried to do was look at all the domains which were hacked
186310	189250	and what kind of mechanism were they using
189250	192870	for storing any kind of sensitive information.
194270	197950	So, this is what my analysis says.
197950	200690	There were around 453 unique domains,
200690	203030	13% were storing it in plain text,
203030	206190	20% as hashes without any salting,
206190	208290	30% as salted hash,
208730	212950	around 15% still using key derivative functions,
212950	214550	which is a great step,
214550	218890	and roughly 23% decided not to disclose,
218890	222550	which in my opinion is plain text,
222550	224990	but no judgments here.
226350	229610	So, looking at it, I was thinking,
229610	233010	okay, why were they breached in the first place?
233150	237310	Most of the times it was because they did not pay a lot of attention
237310	242110	in other kinds of security issues in their applications.
242190	244750	A lot of them were simple SQL injections
244750	248350	where entire databases were dumped out.
248750	252270	Open S3 buckets was not an uncommon thing I saw.
252270	255450	There were a lot of unprotected endpoints,
256090	258770	which kind of leaked this data.
260630	262530	So, that was my first lesson learned,
262530	264770	that why are these things happening?
266790	271350	And now, then mainly my focus was towards thinking about,
271350	273290	okay, this breach has already happened,
273290	275590	or these breaches are always going to keep happening
276230	278830	even for innocent reasons sometimes,
278830	280810	when there is nothing innocent about security.
282690	285430	So, my next thing was, okay, now what can...
285430	288730	what happens after these breaches are done?
289290	291290	And my first thought was like, oh, wow,
291290	294390	the modern computer architecture is getting cheaper and cheaper
294390	298230	and it's going to keep getting cheaper from now on.
298230	303030	All these modern GPUs with extremely high parallelization capabilities
303030	305150	can crack these things in minutes
305150	307510	and making the cost much more...
307510	309830	making the password cost much cheaper
309830	313950	for any kind of offline mechanisms.
314810	321030	With the whole Bitcoin mining philosophy of cracking,
321030	323190	there are so many ASICs...
323190	328090	sorry, application-specific integrated circuits out there,
328090	331890	which makes the cost of cracking much more cheaper.
332970	337070	There are literally trillions of hashes happening within seconds
337070	340810	and this can be easily mapped to any kind of crypto-perimeters.
341230	343670	All these things are going to keep making password cracking
343670	347210	much more cheaper with time.
348170	349950	So, what should we do?
349950	354430	Well, the need of the hour was always stretching this information out
354430	355990	so that it takes...
355990	358270	we have to throw a lot of computational resources
358790	362330	like CPU and memory to compute each password.
362710	364950	With that, we are going to increase the speed
364950	367050	with which the passwords are being calculated.
367070	371150	This will greatly increase the offline cracking time
371930	375510	and making us resilient towards any kind of
375510	378210	modern computer architectures or brute-forcing
378210	382010	or any kind of time-memory trade-off attacks
382010	385830	or rainbow tables, dictionary attacks,
385830	387390	all those kind of things.
388010	390410	So, that's what we really needed.
391030	393470	And how did we achieve that?
394470	397950	Using key derivation functions.
397950	400710	Well, this concept of key derivation function
400710	403450	isn't specific to password hashing
403450	405570	or secret information hashing.
405570	408590	In fact, it came into existence for actually
408590	413370	creating key material out of low-entropy inputs.
414310	417310	But at that time, when everyone were in this
417310	419660	cat-and-mouse race,
419660	423560	people thought that KDFs are much better suited
423560	426740	than just simply storing things as plain hashed
426740	428680	or salted hashes.
428680	432000	It can be much better safeguarded at that time.
433500	436040	And thus, this whole philosophy of using
436040	440980	key derivation functions, KDFs, came into picture.
441160	443740	So, simply how this works?
444360	446580	Well, underlying, there is still an algorithm
446580	449540	which is used, which is iterated hundreds
449540	452120	and thousands and sometimes a couple of millions
452120	455740	of times on a basic crypto-primitive.
456060	459980	This type of functions are called adaptive functions.
461040	463780	And then much more matured ones are throwing
463960	466140	a little or sometimes a lot of memory
466140	468980	to this iterative process, which increases
468980	473880	or almost quadruples the speed of cracking offline.
473880	476920	And still, it takes password and salt,
476920	479720	gives out a fixed length hash,
479720	483200	and it's the work factor which can be tuned
483200	486100	based on different hardware your application
486100	488160	is being deployed.
489540	493260	So, that's going to be the base of our talk today
493260	496140	to protect our safeguard against most
496140	498100	of the offline cracking mechanisms.
500220	503300	Some design considerations I'd like to point out
503300	507640	here is try to save your password hash
507640	510480	and salt in completely different databases,
510480	513800	or a distributed database, or maybe a database
513800	515280	and a property file or something.
515280	517560	They should not be close to each other.
519200	521580	Obviously, you're not going to store a password
521580	523420	in plain text anymore.
524620	528260	I can even go as far as saying that maybe
528260	530840	we can have different work factors
530840	535100	for different information we are trying to safeguard,
535100	537260	or even different logins can have different
537360	540240	work factors and storing work factor
540240	542040	per login, obviously.
544820	549020	With increasing cost in memory or CPU,
549880	553160	it should be routinely checked that work factors
553160	556280	are incremented accordingly to keep making
556280	559080	password offline cracking expensive.
560160	565480	Lastly, how expensive is tolerable or acceptable?
565780	570340	Industry standards are any kind of interactive login,
570440	574740	a latency of around one second is very acceptable.
574740	577240	So make sure you tune your work factors
577240	580320	in a way that the output is calculated
580320	582200	around a second.
582200	586400	This is acceptable latency, and it still increases
586400	589720	the offline cracking time by a huge margin.
590500	593600	And lastly, if you are using your password
594080	596400	or trying to save a password which is not going
596400	598680	to be involved in interactive logins,
598680	601560	like, for example, your hard disk encryption,
602060	604460	a latency of around five to six seconds
604460	607760	is quite acceptable in that scenario.
608000	611060	So those are the things I'd like to say
611060	614700	about key derivation functions in general.
616420	619180	Let's start talking about different
619180	622380	key derivation functions in existence,
622380	625400	starting with adaptive functions.
625880	629220	One of the oldest and the most widely adopted
629220	631860	function was pbkdf2.
631860	634100	Again, it came into picture because
634100	638540	they really needed to generate keying materials.
639080	643180	This function is the only government-approved
643180	645140	function right now, so if you really have to
645140	649300	comply by government standards, I really wish you don't,
649300	653240	then this is probably your only option, unfortunately.
653240	655860	This function is also used as
655860	658920	different crypto-primitive blocks for
658920	661860	other modern functions
661860	664200	these days.
665640	668360	Let's see how this actually works internally.
668840	671020	So just like our generic KDF
671020	674920	working, it still takes a password, a salt,
674920	678140	gives out a password hash. You can actually configure the
678140	680960	size you expect out of a password hash. This feature
680960	683900	was more for... because there is always
683900	686620	requirement of a fixed key size for any kind of
686620	688920	block cipher being used for.
689780	693660	The work factor is in terms of iteration count.
696620	700200	Let's talk a little bit about the internal working of this algorithm.
700620	702540	What it does is it runs the
702540	705120	crypto-primitive it iterates over is
705960	708800	a pseudo-random function, usually a HMAC.
709900	712320	Based on the desired output length
712320	715220	and the block size of the internal hash being used
715220	717720	in the HMAC, different blocks are
717720	720720	generated and those blocks are iterated for the iteration
720720	723840	number of count times. Output is concatenated
723840	726180	and that's your password hash.
727840	730080	So you will see things a little bit
730080	733300	in green color here. What I have done is
733300	736320	I have written a tool which will do
736320	738940	parameter tuning for me based on the
738940	742420	rules of thumb I mentioned earlier about having
742680	745040	a password being calculated in roughly 1 second
745040	748180	for interactive logins and roughly 5 seconds
748180	751820	for any kind of non-interactive logins.
751880	754260	So since PBKDF is government
754260	757340	approved, they say the iteration count or the work factor for
757340	760480	this algorithm should be around 10,000, which is
760480	764340	way lower. Please don't do that. Please increase something.
764380	766500	For a reasonable hardware
766500	769500	on which most of the typical web applications would
769500	771660	be deployed in today's time
773180	774700	EC2T2 instance with
775340	778080	roughly 8 GB of RAM and
779020	781640	x86 architecture. I ran
781640	784160	this tool and the number of iterations
784160	787080	were around 1.5 million for
787080	790400	just 1 second of password calculation. Just imagine
790400	793580	how off the government standards are here.
793660	796280	So I'll highly motivate whichever algorithm
796280	799420	you decide to use among all the algorithms you are going to talk
799420	802100	about. Please run some kind of a tuning
802100	805040	utility. Play around with your parameters.
805040	807660	I'll be open sourcing this tool anyways. You can
807660	810980	feel free to grab it and run it on your
810980	813600	deployment hardware to tune your work factors
813600	814840	accordingly.
817200	819800	Some things you should be worried about when
819800	823380	choosing this algorithm is please choose your
823380	825320	password output length
825980	829160	little less than or equal to the internal hash you are
829160	832400	using. The reason being it unnecessarily
832400	835060	takes a lot of processing power
835060	838200	for a no value add. So that's
838200	839980	one of my suggestions.
840200	843600	In this algorithm, you can just
844520	847400	configure the CPU time involved. There is no
847400	850340	memory involved. It is still not at all resilient
850340	853360	towards any kinds of brute forcing attempts because
853360	856160	of the highly parallelized nature of very
856160	859340	cheaply rentable GPUs in today's
859340	861940	time. If you don't have to comply
861940	865240	with the government standards, please move on.
869380	872480	Next, a notable mention, Bcrypt
872480	876900	is very commonly used.
876900	879080	It is based on a
879080	882480	already deprecated symmetric
882480	886800	cipher called Blowfish.
886960	888760	It involves a little bit of
888760	891480	memory for its internal working. So that's what is
891480	894080	slightly better than pbkdf. But again, that memory
894080	895220	or amount of memory it will need to
895220	899820	use is not tunable by the user.
900000	902000	And again, it was designed for
902000	904980	generating key materials and not with storing
904980	908400	secrets or password hashing in mind.
908420	910840	So how does this algorithm work internally?
910840	914200	Again, we have a password, a fixed size salt,
914240	917620	a password output as a password hash.
918800	919900	Iteration count
919900	922240	is specified in logarithmic
923060	926200	way. So this is going to be 2 raised to 14 number of
926200	929360	iterations. And internally, how it works is it has
929360	930760	this very expensive
933980	936240	BlowCypher key setup process
937080	938380	which involves some
938380	941300	memory. So it iterates around that key setup
941300	944400	and the output is again iterated
944400	946860	through a normal BlowCypher
947940	950300	Blowfish algorithm and the
950300	953220	output is given to the
953220	954260	caller.
956760	959560	It still is a little better than pbkdf
959560	962280	because of the internal RAM usage, but it is
963340	965520	still very susceptible to brute-forcing
965520	968360	attacks, maybe slightly more expensive than the
968360	971720	previous one. And I don't understand
971720	974580	why to use bcrypt, though I've seen a lot of usages
974580	977620	of that. If you don't have to even comply
977620	980740	by the government standards, why not use the more
982420	984180	modern memory-hard
984180	987500	functions. Okay, let's start talking about
988200	991100	a few different memory-hard functions.
991640	993280	The first one being
993280	996080	sCrypt. It's one of the very
996080	998620	earlier generation memory-hardness
999180	1001260	built inside the function.
1002260	1004980	It is having an increased adaptation in
1004980	1008400	cryptocurrencies mainly due to the
1008400	1011360	nature of it. In cryptocurrencies, they don't really need
1011360	1013980	to worry about time-memory
1013980	1016960	trade-off attacks like offline cracking needs to
1016960	1020200	and cryptocurrencies need to be
1020200	1023200	more worried about side-channel attacks, which is not the domain
1023200	1025800	for offline cracking.
1025980	1029060	So it's mainly due to the nature of the applications
1029060	1031900	it's widely adopted in cryptocurrencies. It's not
1031900	1034920	like it's better or less
1034920	1038100	secure for other applications.
1039220	1040660	It was still designed
1040660	1044120	for keying material, but it saw a lot
1044120	1046540	of promising breakthroughs
1046540	1050160	in being used for offline cracking.
1051560	1053160	Okay, let's see how this
1053160	1055960	works. It still has password salt
1055960	1059220	output password we are given. We can still configure
1059220	1062180	the length we desire out of the output.
1063120	1065400	And if you see, the work factor has
1065400	1069340	increased from 1 to almost 3 at this point.
1069560	1071500	And not all are going to be
1072340	1074320	still giving us all the freedom
1074320	1077140	to tune all kinds of resources, but that's a huge step
1077140	1080760	in the right direction, in my opinion, with memory-hardness involved.
1081760	1083240	There is parallelization. You can
1083240	1086440	parallelize the computation. I would like to note
1086440	1089280	here that not all implementations
1089280	1092620	give this control to the user. They still
1092620	1095480	do it the way it depends
1095480	1096900	on the implementation.
1098480	1101860	You would note that there is only one parameter
1101860	1104400	which will control both the CPU resources
1104400	1107540	as well as the memory involved. Basically,
1107540	1109400	it does not differentiate between
1110210	1113420	both the resources we can throw at this algorithm.
1113420	1116500	So basically, going down the line, if we decide
1116500	1119840	that memory is getting cheaper, so we should increase the amount of memory
1119840	1123540	being used in the algorithm, we don't really have a choice here.
1123840	1125800	And finally is the block size which is used
1125800	1128620	internally. Most typical values are 8 or
1128620	1130940	16. It does not make a huge difference.
1133300	1134720	Let's talk a little bit about
1134720	1136820	how the algorithm works internally.
1137020	1141620	While talking about PBKDF,
1141620	1144860	it is used internally from Mac to generate a
1144860	1147980	fixed size password which is looped through this
1147980	1150680	crazy memory array with a lot of
1150680	1153580	stream ciphers and XORing going on for
1153580	1157400	the iteration number of count.
1157400	1160040	And again, the output is made of fixed size
1160040	1162480	by PBKDFing it again and
1162480	1167460	the output is passed to the caller.
1167460	1171600	If you are choosing this,
1173140	1175700	any kind of brute forcing
1175700	1178600	attempts by a huge margin compared to
1178600	1180520	adaptive functions.
1180820	1184000	But the way the memory is being used
1184000	1186660	by the algorithm internally, it is still using
1186660	1189800	adjacent memory arrays in the consecutive
1189800	1193160	operations. What I am trying to say is
1193160	1196780	depending on the value of the password,
1196780	1199380	the consecutive arrays are chosen.
1199380	1202180	So this is always going to be a predefined
1203020	1205520	sequence of memory arrays based on
1205520	1208660	the input password. And what this opens
1208660	1211200	us is towards the side channel
1212360	1213640	attacks.
1215380	1217600	Again, as we spoke about earlier,
1217600	1220140	there is no way we can tune the CPU and memories
1220140	1223320	independently. And since there is a lot of
1223320	1226460	crypto involved in this algorithm,
1226460	1229480	we have HMAC, we have PBKDF, we have
1229480	1232380	Salsa, StreamCyphers, we have
1232380	1235920	Xoring, we again have PBKDF.
1235920	1238120	The number of crypto involved
1238120	1241440	increases, the implementations become more
1241440	1244440	complicated, more error prone, the crypto
1244440	1246840	analysis becomes more complicated and
1247300	1250620	it's not as sneak, basically.
1251360	1253760	So these are the things
1253760	1257060	you should think about if you decide to go with a script.
1257060	1260320	Still a huge step ahead of the adaptive functions.
1260320	1263120	It still reduces the offline cracking cost
1263120	1265940	by a huge margin, almost like a quadruple
1265940	1268060	based on the number of iterations.
1268960	1271780	It's a great choice. Well, don't they say
1271780	1274720	save the best algorithm for the last? And that's
1274720	1276260	what Argon2 is.
1277780	1280860	Around 2015, there was this competition which
1280860	1284500	took place and the goal of that competition
1284500	1287400	was to come out with an algorithm which is
1287400	1290100	specifically suited for storing secrets
1291620	1293500	and safeguard it against
1293500	1296060	any kind of offline cracking, obviously.
1296780	1298880	It wasn't like before that
1298880	1301960	no one was thinking about how to safely store
1301960	1305580	information. Well, the breaches were happening.
1305580	1307980	It was more like a cat and mouse race
1310280	1312760	and the industry started looking at
1312760	1315720	what current tools are there in the
1315720	1318660	cryptography arsenal which we can apply to this
1318660	1321640	particular problem quickly so that
1321640	1324440	they can safeguard their information
1324440	1326940	as long as they can from any kind of
1326940	1329320	offline cracking mechanism.
1331140	1333660	Well, Argon2, the winner of this algorithm
1333660	1336700	is obviously going to take care of all those existing
1336700	1339700	attacks we have been talking about so far.
1339700	1341240	It's very resilient against
1343120	1345920	any brute forcing or dictionary attack.
1345920	1348300	It's very hard to just parallelize it and
1348300	1351760	run computations and start cracking passwords in
1351760	1354860	minutes. They were also very resilient
1354860	1357460	about the modern computer architecture
1357460	1360720	which started maturing, became much cheaper and
1360720	1363360	they were very, very cognizant about it will keep getting
1363360	1366320	cheaper with time. So it's obviously going to be
1366320	1369540	very resilient against any application
1369540	1372380	specific integrated circuit architectures or even
1372380	1374160	FPGA arrays.
1375140	1378360	A few years ago, there were limited
1378360	1381860	implementations of this algorithm out of a
1381860	1385000	direct cryptographic library. But that situation
1385000	1387880	has greatly changed. So congratulations, you don't have to
1387880	1390620	implement this algorithm yourself. You can pick up any
1390620	1393500	programming language, any library in that language
1393500	1395940	and for the most
1397500	1399880	amount of time, you would be having
1399880	1403000	this implementation ready to be plugged and played
1403000	1405500	in your application.
1406880	1409160	So let's see how this algorithm works.
1409160	1411760	Well, you still have your passwords and salts. You still
1411760	1415000	will get a fixed length hashed password.
1415000	1417580	In terms of memory factors, you have
1417580	1420820	three parameters now. One is obviously
1420820	1423860	parallelization. You can configure it based on number of
1423860	1426420	CPU cores you have at your disposal
1426420	1429920	and you can tune the amount of CPU
1429920	1432820	needed in terms of number of iterations and
1433120	1436280	the memory which can be used in this algorithm
1436280	1438940	in terms of memory size.
1438940	1441760	So it basically decouples both the resources
1441760	1444200	resource utilizations.
1444200	1447240	Very unlike sCrypt and one of the huge
1447240	1448840	advantages.
1449940	1452840	There is some crypto analysis done on
1452840	1456160	Argon2 algorithms which makes
1456160	1458980	any iterations below 10
1459800	1461840	a little susceptible but it is more
1461840	1464900	theoretical crypto analysis so don't freak out but
1464900	1468180	choose a parameter which is at least greater than 10 and
1468180	1470180	that's the reason.
1471960	1474420	Talking about modes of operation
1474420	1477540	which is crucial. There are two
1477540	1480900	main types of modes in this algorithm.
1480900	1483600	One is data-dependent mode which is what
1483600	1486600	was there in the previous sCrypt algorithm as well
1486600	1489600	and a data-independent mode which is the
1489600	1492500	best option for password storage and the third
1492500	1495240	one is a hybrid of both the modes working
1495240	1496340	together.
1498240	1500940	How these modes work for that let's start
1500940	1503600	talking about the internal crypto
1504500	1507700	of this algorithm. So how it goes is
1507700	1511120	it first computes a
1511120	1514340	hash of password salt and all these different
1514340	1516960	parameters. Any hash can be used
1516960	1519900	usually it is Blake2.
1519900	1523580	And based on the value of the hash
1523580	1525420	sorry before that there is this memory
1525420	1528960	array which is dedicated to this based on the
1528960	1531760	memory size we give. So just imagine it as rows
1531760	1534980	and columns being populated iteratively for a
1534980	1538840	number of iterations of times.
1539520	1541640	So for data-dependent
1541640	1544580	mode and data-independent mode how it is different?
1544580	1548080	It's like each memory array is being
1548080	1550440	populated in sequence but that sequence
1550440	1553080	in data-dependent mode is decided by the value
1553080	1556240	of the hash which is dependent on the value of the
1556240	1559220	input password. And for data-independent mode it is
1559220	1562360	completely random. So basically
1562360	1565580	what it comes down to is the sequence of memory
1565580	1568320	array populations per iteration is actually
1568320	1571120	based on the input password. And
1571120	1574420	this particular feature of this algorithm makes it
1574420	1576920	susceptible to side channel
1576920	1580420	attacks which is okay for
1581480	1584720	cryptocurrencies but not very comfortable
1584720	1588240	for any kind of password storage.
1588240	1590300	And that's why you should use the
1590300	1593640	independent mode where the sequence of memory
1593640	1596460	array population is completely random and it takes away
1596460	1599420	even that issue which a script had
1599420	1602680	and which even this kind of attacks
1602680	1605640	might have. So some
1605640	1608640	design considerations. You have to tune
1608640	1611920	your parameters a little more carefully and mostly
1611920	1614680	because you have few more parameters to
1614680	1618040	take care of. As we talked about
1618040	1621160	the data-independent mode is more susceptible to
1621160	1623640	any kind of side channel attacks and
1624240	1626660	there is this hybrid mode where
1626660	1630080	the first part of it is happening in independent manner
1630080	1633420	and the next half is happening in the data-dependent manner.
1633480	1635800	And with that we get the best of both worlds.
1635800	1639340	We are resilient towards side channel attacks as well as
1639340	1642920	we are much better with the time memory trade-off issues.
1643580	1645160	So that's what
1645160	1647380	I would say. Use Argon2
1647380	1650980	mainly in 2ID mode. We already
1650980	1654120	looked at what is the best parameter options for
1654120	1657100	an output for password computation
1657100	1658900	within a second.
1660840	1663200	Since Argon2 is the algorithm
1663200	1666020	I am highly recommending to be used for
1666020	1669920	any kind of sensitive information storage.
1670220	1672280	I'd like to quickly show how
1672280	1674800	easy it is to just start using this
1674800	1678880	by any implementations you have access to.
1680000	1681400	Just to record
1681400	1684520	this demo, I had a forked off EC2 instance.
1684520	1687100	These are the details of the instance. It's a typical
1687100	1690060	standard T2 medium with 2
1690060	1693520	CPUs and 4GB of RAM.
1693520	1696160	Currently available as of this moment is
1696160	1699220	around 2.8GB. It's using x86
1699220	1702400	architecture on a Linux kernel.
1703160	1705100	So let's see how quick
1705100	1708400	it is to start using this.
1709580	1711220	Well, I am going to
1711220	1713540	use NACL's password
1714620	1717340	module where the Argon2 ID is
1717340	1720040	being supported. Well, a quick pro tip
1720040	1722820	whenever given a choice of any
1723170	1725900	crypto implementation you need
1725900	1728940	if you have a choice, always go for NACL. It's
1728940	1732280	very cleanly written by cryptographers rather than
1732280	1735580	actual developers. They deprecate
1735580	1738300	things which are no more secure or better
1738300	1741360	options are available out there. They quickly deprecate all those
1741360	1744060	things from anyone's view. So chances of
1744060	1747280	making wrong choices are eliminated.
1748440	1750040	Okay, coming back to the
1750040	1753280	code, we are going to use that module and just
1753280	1756160	to keep track of time, we are going to use the time module.
1756280	1758300	Start time is going to be
1758980	1761620	current time. Let's start
1761620	1763940	storing the password.
1767360	1769380	First, let's use the
1770340	1770900	module
1773980	1775260	hash.argon2id
1775260	1778060	Why not use the hybrid one? Best of both
1778060	1781120	worlds, right? And the string
1781120	1783960	output for that. Giving the
1783960	1785040	password
1789450	1792630	long is better than higher, entropy
1792630	1795810	shorter one. So that's what I choose for.
1796350	1798730	Ops limit is the number of iterations
1798730	1801530	around the memory array. Let's go for 14
1802770	1804210	till 10 is already
1805190	1807830	theoretically crypto-analyzed. So anything
1807830	1809810	about 10 is great.
1811670	1813950	And the key thing, memory.
1814530	1816910	It's again logarithmically given.
1817330	1820530	We already know the answer from our tuning tool.
1820750	1822530	So let's see. This is
1823090	1826190	as short and sweet as it can get actually.
1826570	1829330	And just to keep track of time,
1829330	1831630	let's see how much it is.
1832350	1835750	And hopefully this compiles and runs actually.
1836850	1838730	Okay, so it took
1838730	1840990	around 1.1 second.
1841990	1845510	Can we go any higher? Let's see.
1845550	1847630	Going from 27 to 28
1848970	1850170	which is
1852450	1853750	2.3
1853750	1856910	I'll leave that choice to you at this point.
1856910	1860870	This is how we should typically tune any parameters.
1866210	1866810	It's almost
1866810	1869950	second nature to wonder how these functions actually
1869950	1872050	compare against each other.
1872610	1875850	There is not a lot of research done
1875850	1879110	in this topic about
1879110	1882230	how to actually put a dollar value
1882230	1884650	or number of years of cracking a particular
1884650	1887090	breach mechanism or
1887790	1891170	There is no apples to oranges comparison as well
1891170	1892990	you could imagine.
1893210	1896250	But good notable work is being done by
1896250	1899950	these two papers. One released in USENIX
1900470	1902950	a couple of years ago and another one done
1902950	1905690	in conjunction between Microsoft and
1905690	1907510	Purdue University.
1908030	1910270	In the most trivial way, what they do is
1910270	1914050	they look at the latest hardware and the memory cost
1914050	1917490	and just start calculations
1917490	1918970	from there.
1919930	1923320	And that's what I tried to do it as of yesterday.
1924370	1926250	So for adaptive functions
1926250	1927670	it's just going to be again
1928750	1931990	a huge list of disclaimers here before I actually
1931990	1934790	talk about this very very cautiously actually.
1936250	1938550	I'm assuming the keyword, the password
1938550	1939990	the sort, the output
1939990	1943130	all those things are same across
1943130	1946230	all these functions. I'm also assuming there is
1946230	1948430	no electricity cost involved.
1951590	1953030	Talking about
1953030	1955110	these figures for adaptive functions
1955110	1957890	it's just going to be as simple as number of iterations per
1957890	1960910	cost of hardware. And the cost of
1960910	1964430	hardware is much easier to calculate
1964430	1967370	these days because most of the modern A6
1967370	1971210	hardwares for Bitcoin mining come with that statistics.
1971210	1973670	So looking at one of the most leading
1973670	1976510	hardware in that department coming from
1976510	1977530	Antminer
1978970	1982630	one of the best configured one
1982630	1985650	is around $2500 and it
1985650	1988370	promises to do 110 trillion
1988370	1991690	hashes per second. And trillion is 10 raised to
1991690	1994310	12 if you are wondering as I was.
1995470	1997170	So using that
1997170	1999730	configuration with the number of iterations
2000190	2003510	adaptive function is going to take so much time.
2003510	2006570	The point being it's going to be extremely cheap
2006570	2008630	to just crack these passwords
2009310	2012450	considering this decently priced machines
2012450	2016050	are going to be in common people's hand very soon.
2016890	2018310	And similarly for memory
2018310	2021290	hard functions and I want to stress here that this is only
2021290	2024370	for memory hard functions which is running in the data
2024370	2027610	dependent mode where the array used
2027610	2030290	for memory calculations
2031010	2033710	is based on the input passwords.
2034070	2036430	So where again the cost is going to be
2036430	2039490	more based on memory as well
2039490	2042010	as the amount of time it takes which
2042010	2044630	pretty much quadruples in memory hardness
2045490	2048650	is going to be much more expensive compared
2048650	2051770	to adaptive functions. And this is just for
2051770	2054770	data dependent mode. For data independent mode
2054770	2057950	well the cost might still be the same but the number
2057950	2060370	of guesses is going to be exponential.
2060710	2063590	So this is just sharing
2063590	2066750	some statistics still in a more conservative
2066750	2067830	tone.
2069850	2072950	This is all what I wanted to speak about today
2072950	2075730	around offline cracking
2075730	2078790	different mechanisms we can use to
2078790	2082030	safeguard ourselves. Key derivation function
2082030	2085230	being the key of that. How to tune
2085230	2086250	different parameters
2087910	2091210	and what kind of design concentrations you should be
2091210	2093970	doing while picking each one of that.
2095190	2097110	Next I'd like to talk about
2097250	2099910	a little bit about how all this information
2099910	2102850	can be mapped to storing any kind of secrets you
2102850	2106790	need to. For that you need to sit down
2106790	2109730	and do a little bit of threat modeling for your
2109730	2112290	own usages. Something like
2112290	2115650	what is sensitive to your business?
2115650	2117850	Do you need to comply with any GDPR
2118410	2121310	requirements? Are you storing any personally
2121310	2123310	identified information?
2124130	2127530	Can it be used for crafting further attacks against
2127530	2129490	the users whose
2129490	2132710	information might be breached?
2134070	2136270	How are you storing that information?
2136270	2139730	Are you storing it in a database? Which fields are involved in that database?
2139730	2141350	All those things need to be
2141350	2144790	thought about and you can easily map
2144790	2147970	all these KDFs to work for your own
2147970	2149470	needs.
2150550	2153010	Lastly, you must have come across
2153010	2156690	countless suggestions and
2156690	2159710	password hygiene requirements or
2159710	2163590	tips over years since it is such a
2163590	2166970	key aspect of any kind of authentication
2166970	2168970	mechanism.
2169270	2172230	Just for the completeness of this talk, I'd like
2172230	2175070	to say a few things about it. Always
2175210	2178230	choose a unique password. Password managers
2178230	2181450	are great. Please use those.
2181450	2183570	Longer passwords are better than
2183570	2186250	shorter, higher entropy ones.
2187370	2190390	This is what I typically do. I store
2190390	2193490	my passwords in a password manager.
2193490	2196230	This is the configuration I use while generating any new
2196230	2199550	password. I choose a longer password and with a
2199550	2201910	reasonable amount of entropy.
2201910	2205450	The point I'm trying to make is there is a lot of crypto analysis
2205450	2207790	done which points us
2207790	2210720	towards the theory that longer
2210720	2213720	passwords are better than shorter ones
2213720	2216500	with higher entropy. A password whose length is
2216500	2219660	25 or 30 characters is far better
2219660	2222340	than a password which is of
2222340	2225660	8 or 10 characters standard length with
2225660	2228820	two special characters, one uppercase and two
2228820	2231920	digits and those kind of things.
2232500	2233840	So do that.
2233840	2237520	The website we looked at about
2237520	2240840	the data breached information, they have
2240980	2243840	a nice API exposed by
2243840	2246800	again Troy Hunt. It would be great to
2246800	2249620	use that API in your websites or even
2249620	2252260	password managers can start using that where
2252260	2255680	if a password which has already been seen
2255680	2258980	in a breach is being
2258980	2261180	used, then they would be flagged and
2261880	2263940	that would go a long way.
2263940	2267180	Finally, in conclusion, please
2267180	2270080	embrace adaptive key derivation
2270080	2273020	functions. Use memory hard functions based
2273020	2276020	on your choice and comfort level with the amount
2276020	2278960	of crypto analysis done. Please don't
2278960	2281540	do plain text or hashing or
2281540	2284940	your own DIY designs. Those are all silly things in
2284940	2288060	today's time. Consider upgrading your
2288060	2290900	work factors based on the resources
2290900	2293840	cost out in the market.
2297420	2299300	Consider having unique
2299300	2300800	work factors for
2302100	2304140	information you are trying to save or
2304140	2307860	for each different user as well.
2308200	2310440	Password hashing suggestion longer is better
2310440	2313520	than shorter with a higher entropy. Keep
2313520	2316440	using passwords. Keep auditing your passwords for
2316440	2319820	its existence in any breaches.
2320540	2323260	And finally, I would like to conclude
2323860	2326480	a huge thanks for giving me this opportunity
2326480	2329740	to share my thoughts. My DMs
2329740	2333340	are always open for any interesting conversations.
2333340	2335580	I blog a lot about these things
2335580	2338880	in much more detail than what a
2338880	2342280	45-minute slot is going to ever allow me to.
2342280	2344460	And finally, you will find all
2344460	2347300	these algorithms implemented in Java as well
2347300	2352220	as the tuning tool on my GitHub repo.
2352340	2353580	Thank you.
2381370	2383290	That was talk how to store sensitive
2383290	2386150	information in 2020 and do's, don'ts,
2386150	2388490	and how-tos of cryptobuilding blocks used in Java.
2388490	2391730	Thank you again to Mansi. We have them right here
2391730	2394270	for a live Q&A, so please put your questions in the
2394270	2396830	Discord CPB Q&A channel.
2398750	2401390	So just to start off, what's the reason
2401390	2405670	for high memory usage is a requirement for KDFs?
2405670	2407790	This is from Discord, by the way. I understand
2407790	2410610	it helps make implementing ASICs harder, but I don't
2410610	2411870	understand why.
2412810	2416490	Sure. So ASICs, in my opinion, really started
2416490	2419590	coming into existence because of the
2419590	2422150	underlying bit mining philosophy
2422150	2425830	is increasing the computation over and over again
2425830	2428410	much, much faster. The hardware
2428410	2431790	is still expensive and
2431790	2435150	throwing memory at it will just make it much more
2435150	2438990	expensive for a widespread adoption,
2438990	2441390	actually. And that would
2441390	2444710	ultimately add to the cost of cracking passwords
2444710	2446430	offline, in my opinion.
2447090	2450010	Again, we have not seen the future. We don't know what quantum
2450010	2453230	is going to get us, but for foreseeable future,
2453230	2455970	for whatever the current theoretical crypto
2455970	2459090	analysis says, that's what it is.
2459810	2462570	Awesome. We have another question.
2463110	2465370	When memory is the bottleneck, is there still
2465370	2468390	an advantage to using ASICs, or does it revert to only
2468390	2471330	negligible gain over general-purpose CPUs?
2472190	2473730	Well, we still have a huge
2473730	2477210	iteration factor, right? So it's a combination of both.
2477210	2480010	So a general-purpose CPU can't be
2480010	2483130	that highly paralyzed with the amount of memory required
2483130	2485630	for each thread. So, yeah.
2487290	2489190	Cool. Another question that we have
2489190	2492130	is, does a salt need to be just
2492130	2495010	unique instead of being that big to avoid having two
2495010	2498170	passwords hash the same thing? This is in relation to 64
2498170	2500410	bits versus, say, 128 bits.
2500730	2504290	Sure. Well, 64 bits is, like, the pure
2504290	2507190	minimum requirement anyways from a standard
2507190	2510170	which was written, like, at least half a dozen... I mean, at least
2510170	2513550	five or six years ago. I don't remember right now.
2513550	2516090	Actually, even more. This is PBKDF, probably.
2516750	2519390	So, I mean, a little bit more salt.
2519390	2522190	128 is not unacceptable. It's not going to add
2522190	2525390	hugely to the processing power. Yeah, it's
2525390	2528170	not a hard requirement. Even CSPRNG
2528710	2531130	is, like, maybe a little too much crypto
2531130	2533950	kind of a situation. So, yeah.
2534050	2537530	It's a little bit on the higher side, but that's okay, in my opinion.
2537530	2540790	It does not add to the computation at all.
2541710	2544630	Awesome. Another question we have,
2544630	2546770	and there were some side parts to this, of course, in chat
2546770	2549730	if you want to go further into them, as I saw. But the
2549730	2552790	question was, any thoughts on using Libsodium, the fork,
2552790	2555750	instead of NACL? I have had great experiences
2555750	2558630	with it. Yeah, Libsodium
2559070	2561930	is great. It is being adopted much more widely, as
2561930	2564590	I stood corrected. NACL is last
2564590	2568070	made at least five, six years ago.
2568470	2570950	I have a slight preference for NACL just because
2570950	2573770	I like the documentation and the names of the APIs
2573770	2576770	and the ease with which they are taking
2576770	2580050	away all the more options
2580050	2583030	you give, the higher the chances of it actually going
2583030	2586010	wrong. So that way I feel NACL is slightly
2586010	2589070	better. But Libsodium is absolutely great anyways.
2589490	2591550	So that's my personal preference.
2592510	2595570	Awesome. Does anyone have any other
2595570	2598470	Q&A questions? Please drop them into the Discord
2598470	2599330	now.
2601930	2604670	This is in the CPB Talk Q&A text
2604670	2615850	channel. And we just wait
2615850	2618890	for a little bit. Also, thank you so much for your talks. These are
2618890	2621750	really lovely, and I'm really excited for the next one to be replayed
2622270	2623130	again soon.
2623130	2627510	Thank you. I'm having a lot of fun
2627510	2629870	watching me talk for two hours.
2629870	2633770	Oh, man, that's a lot of anxiety
2634450	2635950	for me at least.
2636690	2637890	That's fun.
2641080	2644700	I think we have someone typing. Oh, no, just people
2644700	2647080	love your talk. Thank you.
2647200	2650180	Let's see if this last person has a question.
2657030	2659190	All right. Thank you again,
2659190	2662030	Mansi, for all your time with us. We hope you
2662030	2664910	take care. Enjoy the rest of Crypto Village and DEF CON.
2665150	2667930	We will love to see you in our Discord
2667930	2668830	soon.
2669990	2674270	Please stay safe, everyone. Please stay safe. Thank you. Bye-bye.