| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 2 months |
| seen | yesterday | |
| stats | profile views | 13 |
|
May 23 |
awarded | Scholar |
|
May 23 |
accepted | Why standards organizations give so short protection times for 128 bit encryption? |
|
May 22 |
asked | Why standards organizations give so short protection times for 128 bit encryption? |
|
May 16 |
awarded | Nice Question |
|
Apr 30 |
comment |
Prevent denial of service attacks against slow hashing functions? very interesting topic generally. i bookmarked several related links to study about client puzzles/PoW. but seems to me that a C program can solve the puzzle much faster than javascript, and that seems another deficiency for web usage. |
|
Apr 30 |
comment |
PHP - Serializing user inputs yes i know all of that. that entropy is just an extra, not the main entropy source. also it is stored in db and is combined with each new request's entropy from every user. so the main extra entropy source (the combined entropy of all requests to the time) becomes completely unpredictable soon after enough distinct users visit the site. also i agree with u that user knows his request parameters, these parameters can't protect the server against user, but that entropy still is of use for protecting user against attackers. e.g it is used in generating users' login key, anti-csrf token, etc. |
|
Apr 30 |
asked | PHP - Serializing user inputs |
|
Apr 28 |
comment |
Web & insecure HTTP - Using RSA for encrypting passwords on the client side i think of, maybe sometimes an http request is passing through an attacker controlled machine/route only once or rarely. don't seems to me that attacker is ready and functional for preforming active attacks against all such requests belonging to different web sites with different codes. i think there is even the possibility that the corresponding response be passed through a different route, so the attacker can't get the results. but plaintext passwords from any http request going to any web site can even be detected and collected automatically. |
|
Apr 28 |
comment |
Web & insecure HTTP - Using RSA for encrypting passwords on the client side i think active attacks need more knowledge/skills, careful prior tests and planning, more risk of detection, more resources, tools, ... so seems not everyone can always perform active attacks effectively. |
|
Apr 28 |
comment |
Web & insecure HTTP - Using RSA for encrypting passwords on the client side i am not discussing about whether HTTPS should be used instead of HTTP. u think what fraction of web that should be using https is really using it? do u really think that the only reason for this is ignorance? |
|
Apr 28 |
comment |
Web & insecure HTTP - Using RSA for encrypting passwords on the client side please read my comment carefully. i said protection against passive attackers only. are all attackers always active and can they be? |
|
Apr 28 |
comment |
Web & insecure HTTP - Using RSA for encrypting passwords on the client side the reason i want to protect password is the same reason why we don't store plaintext password on the server side and use a hash instead. the benefit of that hash is for when the system is already compromised (at least to some extent); we want to limit the potential damages that can be done. e.g. plaintext passwords can be used to attack the other (not compromised) accounts of users. likewise, i want to limit the damage from passive adversaries/eavesdroppers when the requests are in transit over insecure channels. i think not all attackers are or can be active (always). |
|
Apr 28 |
revised |
Web & insecure HTTP - Using RSA for encrypting passwords on the client side added 16 characters in body |
|
Apr 28 |
revised |
Web & insecure HTTP - Using RSA for encrypting passwords on the client side added 16 characters in body |
|
Apr 28 |
asked | Web & insecure HTTP - Using RSA for encrypting passwords on the client side |
|
Apr 28 |
comment |
Using MD5 for file integrity checks? Maybe MD5(SHA256(data)) is a good compromise between security and storage space; but of course has no performance benefits (somewhat slower than SHA256). |
|
Apr 24 |
revised |
Truncating the output of SHA256 to 128 bits added 29 characters in body |
|
Apr 24 |
asked | Truncating the output of SHA256 to 128 bits |
|
Apr 24 |
comment |
Using MD5 for file integrity checks? don't u think truncating SHA-256 output is nevertheless more secure than using an older and broken algorithm? |
|
Apr 19 |
comment |
Using MD5 for file integrity checks? can't we concatenate SHA-256's output to 128 bits if needed? |