We need a "salt" for used passwords.

For the two passwords entered by the user, called:

1.- Identity Unlock Access Code. (used to decrypt the IdUK).
2.- Operating Authentication Password. (used to decrypt the IMK).

both are fed to Enscrypt functions and the resulting key is used to decrypt 
the OCB block secret. (See https://www.grc.com/sqrl/key-flow.htm).

The problem is that the enscrypt is supposed to provide a time delay, a 
forced slowness in the system which very much increase the strength of the 
two passwords. This time delay may be bypassed by a pre-computation (rainbow 
table) of the Enscrypted value. The way to ensure the strength of the 
Enscrypt function is to record a random "salt" tied and "stored with" the 
"encrypted IdUK".

Any reasonable salting operation should do, something like:
    enscrypt key = SHA128( password || salt )

An interesting read about salting:
http://www.jasypt.org/howtoencryptuserpasswords.html


-- 
Mark Cross @ 02/11/2014 2:34 p.m.
For good, return good. For evil, return justice.

0
Mark
2/11/2014 6:52:42 PM
grc.sqrl 459 articles. 0 followers. Follow

12 Replies
373 Views

Similar Articles

[PageSpeed] 32

On 14-02-11 01:52 PM, Mark Cross wrote:
> For the two passwords entered by the user, called:
>
> 1.- Identity Unlock Access Code. (used to decrypt the IdUK).
> 2.- Operating Authentication Password. (used to decrypt the IMK).
>

> This time delay may be bypassed by a pre-computation (rainbow
> table) of the Enscrypted value. The way to ensure the strength of the
> Enscrypt function is to record a random "salt" tied and "stored with" the
> "encrypted IdUK".
>
> Any reasonable salting operation should do, something like:
>      enscrypt key = SHA128( password || salt )
>

I would normally agree with you in that pre-computation of rainbow 
tables is a big problem when the PKDF is singular, known and quick. For 
example https://www.freerainbowtables.com/en/tables2/ .

But I'm not sure it would be needed in this case and here is my reasoning.

For any given use of an SQRL client on a platform the first use of 
EnScrypt will spit out for the two passwords the two keys plus two 
values for the iteration count (i).

Taking one key and say a range of values for 'i' that would mean 
building an exhaustive if possible rainbow table for each value of i. 
Where each table would be:

{password: say max 128 bits, key: 256 bits } * number of passwords to 
seach + (i: 8 bits) * range of i.

so assuming a choice from a weaker set IUK/IMK keys of only 44bits 
entropy and a range of i from 1 to 50 we would need a rainbow table of:

((128 + 256) * 2^44 + 8) * 49 = 3.3 * 10^17 bits or 36.75 Petabytes

or a stack of 5.25 inch 3TB drives approximately 326 meters tall.

Also let us assume we can to 1000 times better than the assumed 1 second 
EnScrypt chosen period for calculating this. It would still take:-

2^44 * 0.001 * 50 seconds to just calculate the table or 27,873 standard 
years.

For myself and for the next say 30 years of Moore's Law I can forgo a 
salt if it means keeping things simple. But if there is no additional 
complications added to the how things work then by all means add one.

0
ramriot
2/11/2014 8:05:38 PM
[for the unabridged version, see Mark Cross's post above]

> For the two passwords entered by the user, called:
> 
> 1.- Identity Unlock Access Code. (used to decrypt the IdUK).
> 2.- Operating Authentication Password. (used to decrypt the IMK).

I agree that we need it for the user's provided password.
But I think nowhere else.  No other salt, nor IV's anywhere.

(An initialization vector is only needed with block ciphers when 
it might be possible for the SAME password to be used to encrypt 
DIFFERENT information.)

FWIW, it's something I've given a lot of thought to, but I 
haven't yet made time to lay out.  Obviously... I will.  :)

I believe that we're going to wind up storing 1024 bits of 
information in the client:

256-bit Encrypted Unlock Key.
256-bit Identity Lock Key.
256-bit Encrypted Identity Master Key.
128-bit Salt for user's OCB-encrypted Password.
128-bit Authentication tag for OCB-encrypted Password.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/11/2014 8:28:01 PM
Steve Gibson was heard to say :

[snip]
> I believe that we're going to wind up storing 1024 bits of
> information in the client:

> 256-bit Encrypted Unlock Key.
> 256-bit Identity Lock Key.
> 256-bit Encrypted Identity Master Key.
> 128-bit Salt for user's OCB-encrypted Password.
> 128-bit Authentication tag for OCB-encrypted Password.

Then that is already included, nothing else to add IMO, then :-)

-- 
Mark Cross @ 02/11/2014 4:35 p.m.
When a hundred men stand together, each of them loses his mind and gets 
another one. — Friedrich Nietzsche

0
Mark
2/11/2014 8:37:11 PM
[for the unabridged version, see Mark Cross's post above]

Mark,

Since I have time before the podcast, responding more directly 
to your note:

> For the two passwords entered by the user, called:
> 
> 1.- Identity Unlock Access Code. (used to decrypt the IdUK).
> 2.- Operating Authentication Password. (used to decrypt the IMK).
> 
> both are fed to Enscrypt functions and the resulting key is used
> to decrypt the OCB block secret.
> (See https://www.grc.com/sqrl/key-flow.htm).
> 
> The problem is that the enscrypt is supposed to provide a time
> delay, a forced slowness in the system which very much increase
> the strength of the two passwords. This time delay may be bypassed
> by a pre-computation (rainbow table) of the Enscrypted value. The
> way to ensure the strength of the Enscrypt function is to record
> a random "salt" tied and "stored with" the "encrypted IdUK".
> 
> Any reasonable salting operation should do, something like:
>     enscrypt key = SHA128( password || salt )
> 
> An interesting read about salting:
> http://www.jasypt.org/howtoencryptuserpasswords.html

I agree with all of that.

We're saved, I think, in the case of the so-called "Access 
Code" because it's <<some number to be determined>> of high-
entropy random bits.

Given the parameters we'll be using for the IUK Access Code 
EnScrypt operation... it just won't be feasible for that 
keyspace to be traversed.

(Note that I haven't yet caught up with postings here, and 
specifically with your posting about the overdesign of password 
length... which, from a distance, sounds like good news. :)

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
2/11/2014 8:53:48 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--BCSA8eIpiprH01M46AAlMPwkGMnpUEgK6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Am 11.02.2014 21:53, schrieb Steve Gibson:
> it just won't be feasible for that=20
> keyspace to be traversed.

Isn't the very idea of rainbow tables that not all of the keyspace (=3D
brute force) has to be traversed in order to get a valid initial value
for any given hash?

Best regards,
Karol Babioch


--BCSA8eIpiprH01M46AAlMPwkGMnpUEgK6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJS+pA4AAoJEHSaZc1HnzIV/3YQAIzcw8tC8RFiYgbFHP1eK6gl
QEAognRkRsWf8SyRR7G+n9VG3XbJKb6FZMtVDYrN22AM1eLr1SgFJn66jrrSDNZE
cnoqkyYIJbrhinzhz606RHI2SUfRmrzx1IbvhgDcFUn/qmpiDjbj01slZupQwd/W
6opd37tg3dB5quZLy8ijBMwsGUdQPh4u5V7JJbePa0fnxfVJ9BePcXexRC4R0jZw
YoqSlie6G4CysfpGGtAY9lCi83tcWk1+j99wv/C4NZVUXOyjdil2ouovbWferdUp
o9QXS4q8dY/lmmYFmwLGUBG3YdpNgJ4DgElhCGjoHnJLQykwtuoO74WJERLJFaIR
uh/3ntdJ4f5R0/Oo+mBDUQOuR6pae4hxmJ9X7r59seXLifPOiABkXZJqbatR+qG0
qkB/p44EQYcURc3KLxgrBkxYIbqM5mJERiOvL7/QXyOPeCnDKHoKelYwDGTwuBeP
vBYRr/szCh+qhe2dPezQKtmUPuP6fyUyL6Kf3aOtXYHhGDLVDHtAIcrj1ldT8K2g
jsbj+bp50UJwNlK3Oy4OaUg8DVzbDlvWK2NZP0i8Puuhd3MnCxyHy6bjzamm60hi
eVDW0MzcxbEj9vI7QMAxe+sBC+S4DrU78dLqMDGunvanMrAzQ5CQ7CdaULqXMx3b
ZzbxH0BpPgjJ65iR/pHS
=jxxz
-----END PGP SIGNATURE-----

--BCSA8eIpiprH01M46AAlMPwkGMnpUEgK6--
0
Karol
2/11/2014 9:03:52 PM
Steve Gibson was heard to say :

[...]
>> Any reasonable salting operation should do, something like:
>>     enscrypt key = SHA128( password || salt )

> I agree with all of that.
> 
> We're saved, I think, in the case of the so-called "Access
> Code" because it's <<some number to be determined>> of high-
> entropy random bits.

Well, yes, in a way you are correct. If the <<some number to be determined>> 
of high-entropy random bits is around (near) the maximum of 128 bits for 
OCB, you get nothing deeply better by using a salt, as the then the brute 
force will be done by substituting the output of the enscrypt function by a 
counter, yes, a 2^128 counter and a lot of numbers, but that is the nature 
of the attack. Just bypass the Enscrypt function and do a very fast, simple 
scan for all the encoded numbers. That is what we need to be sure is around 
the intended strength.

Using a "salt", and a 128 bit salt just makes sense as nobody will write it 
and changes nothing in the way the user interacts with the application, 
makes the password become close to 128 bit strength in result. That is what 
we should try to keep, even for a shorter password.

> Given the parameters we'll be using for the IUK Access Code
> EnScrypt operation... it just won't be feasible for that
> keyspace to be traversed.

You can set a counter in substitution to the output of the enscrypt 
function, the effect over the OCB will be exactly the same, and is a lot 
(and I do mean a lot) faster. But yes, the size of 2^128 is very big, I 
agree.

The question is which way is easier or faster, and more to the point, which 
will be faster in two years time. Scrypt may break, OCB may become softer 
(although OCB softening seems like a hard bet). In any case, a SHA128 is 
very-very fast to do.

> (Note that I haven't yet caught up with postings here, and
> specifically with your posting about the overdesign of password
> length... which, from a distance, sounds like good news. :)

I hope I didn't fall in any obvious mistake, but you people will sure find 
it if it's there ;-)


-- 
Mark Cross @ 02/11/2014 4:57 p.m.
A word to the wise ain't necessary – it's the stupid ones
that need the advice. — Bill Cosby

0
Mark
2/11/2014 9:13:31 PM
On 2014-02-11 12:05, ramriot wrote:
> On 14-02-11 01:52 PM, Mark Cross wrote:
>> For the two passwords entered by the user, called:
>>
>> 1.- Identity Unlock Access Code. (used to decrypt the IdUK).
>> 2.- Operating Authentication Password. (used to decrypt the IMK).
>>
>
>> This time delay may be bypassed by a pre-computation (rainbow
>> table) of the Enscrypted value. The way to ensure the strength of the
>> Enscrypt function is to record a random "salt" tied and "stored with" the
>> "encrypted IdUK".
>>
>> Any reasonable salting operation should do, something like:
>>      enscrypt key = SHA128( password || salt )
>>
>
> I would normally agree with you in that pre-computation of rainbow
> tables is a big problem when the PKDF is singular, known and quick. For
> example https://www.freerainbowtables.com/en/tables2/ .
[...]
> {password: say max 128 bits, key: 256 bits } * number of passwords to
> seach + (i: 8 bits) * range of i.
>
> so assuming a choice from a weaker set IUK/IMK keys of only 44bits
> entropy and a range of i from 1 to 50 we would need a rainbow table of:
>
> ((128 + 256) * 2^44 + 8) * 49 = 3.3 * 10^17 bits or 36.75 Petabytes

I'm not quite following the size formula there -- rainbow tables provide 
significant compression compared to storing all possible hash outputs.

44 bits is roughly comparable to a 7.4 character random, case-sensitive 
alpha-numeric password. There are rainbow tables going up to 9 
characters available for many common hashes, and they weigh in at around 
1TB apiece. The 8-character tables weigh in at only ~200GB. You'd need 
one such table for each iteration count.

eg "sha1_mixalpha-numeric#1-8"

> or a stack of 5.25 inch 3TB drives approximately 326 meters tall.
>
> Also let us assume we can to 1000 times better than the assumed 1 second
> EnScrypt chosen period for calculating this. It would still take:-
>
> 2^44 * 0.001 * 50 seconds to just calculate the table or 27,873 standard
> years.

Or, an attacker accomplishing that same 1,000 times speedup could 
purchase a year on a cluster similar to this:
http://arstechnica.com/business/2011/09/30000-core-cluster-built-on-amazon-ec2-cloud/

At $1,200+ per hour, that is only about $10 million to create the 
rainbow table. And that amount of storage needed isn't really 
prohibitive for a cluster that size.

So if we propose 44-bit, unsalted, passcodes, we can put a cost 
somewhere above $10 million to permanently and irrevocably break all 
SQRL passwords as lookups from that point onwards would have negligible 
cost.

So either 44 bits is too short, or salt is still needed.

Varied iteration counts shouldn't really be counted on to make the 
pre-comutation harder, either, just more time-consuming. Using the 
iteration count in that way makes it, in effect, a very tiny salt. If we 
are discarding salts, we should also consider using a single, fixed 
iteration count, by the same logic.

Counting on the different iteration counts just means attackers with 
multiple rainbow tables covering common iteration counts. There just 
aren't enough bits of variation there for it to have the same impact as 
a real salt.

Regards,
Sam
0
Sam
2/11/2014 10:28:58 PM
On 2014-02-11 12:53, Steve Gibson wrote:
> [for the unabridged version, see Mark Cross's post above]
[...]
>> An interesting read about salting:
>> http://www.jasypt.org/howtoencryptuserpasswords.html
>
> I agree with all of that.
>
> We're saved, I think, in the case of the so-called "Access
> Code" because it's <<some number to be determined>> of high-
> entropy random bits.

I would suggest the following compromise position: In order to provide 
equivalent-to-cipher resistance against pre-computation, for a N-bit 
cipher (eg, 128, 256), the total randomness used to derive the key ought 
to be equal to or greater than N-bits. So with 256-bit AES, if the 
passcode provides 128-bits worth of entropy, then a 128-bit salt is an 
entirely appropriate defense against precomputation.

Hmm, actually, that math doesn't really work out at all. A 128-bit key, 
with a 128-bit salt will still fall to brute-force in 128-bits worth of 
work. That work just won't be re-usable to break multiple keys. If an 
attacker wanted to precompute *all* of those salts for *all* passwords 
it would take work equivalent to breaking a 2^256-bit key (2^128**2^128 
as opposed to 2^128*2^128).

But that approach would be severely sub-optimal as this will still 
remain significantly weaker than the cipher against pure brute-force, as 
the salt is not a secret. Ignoring any PBDKF-obtained slowdown, of course.

For a pre-computation attack you could effectively ignore the PBKDF 
slowdown as it is a cost that the attacker only spends once. If the 
range is small enough that the attacker could conceivably compute a 
table, the attacker will do so.

In other words, PBKDF's provide substantial protection against 
brute-force, but much less against rainbow tables and the like (IMO). 
Sure, a rainbow table lookup requires *some* use of the hash/PBKDF, but 
the number of iterations required is inversely proportional to the 
storage space used (you can sacrifice storage to make lookups faster).

With a rainbow table, the time-memory benefit to using a rainbow table 
for a given input set becomes progressively more advantageous the harder 
the PBKDF becomes -- the input set being used to populate the rainbow 
table is only ever processed once.

Of course, there are key lengths where the availability of memory to 
construct a rainbow table becomes problematic. *g*

All of that said, I would be very cautious about discarding the use of a 
salt. In any situation where a PBKDF is considered useful, using a salt 
magnifies the protection provided by the PBKDF against certain attacks. 
If the passcode is long enough to not "require" a salt that is also just 
as much an argument against the use of a PBKDF, IMO. So if a PBKDF is 
worth using, then a salt should be worth using as well. IMO, of course.

We could always move to passcodes that are as long as the cipher key 
length, and just call them symmetric cipher keys, which would be what 
they are. In that case, salting and a PBKDF are indeed irrelevant as the 
attacker can *always* fall back to brute-forcing all possible 128-bit 
keys if we use AES-128 (and so on).

Regards,
Sam
0
Sam
2/11/2014 10:42:33 PM
On 2014-02-11 13:03, Karol Babioch wrote:
> Hi,
>
> Am 11.02.2014 21:53, schrieb Steve Gibson:
>> it just won't be feasible for that
>> keyspace to be traversed.
>
> Isn't the very idea of rainbow tables that not all of the keyspace (=
> brute force) has to be traversed in order to get a valid initial value
> for any given hash?

Constructing the rainbow table does, however, require traversing the 
entire key space and storing a substantial fraction of the results.

Rainbow tables do quite well storing things like relatively short random 
permutations, such as all alphanumeric combinations up to 10 characters, 
but even that kind of thing can require te. And each additional bit of 
entropy in the input set used to create the rainbow table will cause a 
logarithmic increase in the table's size (or alternately, increase the 
lookup time).

0
Sam
2/11/2014 11:19:44 PM
On 2014-02-11 15:19, Sam Schinke wrote:
> On 2014-02-11 13:03, Karol Babioch wrote:
>> Hi,
>>
>> Am 11.02.2014 21:53, schrieb Steve Gibson:
>>> it just won't be feasible for that
>>> keyspace to be traversed.
>>
>> Isn't the very idea of rainbow tables that not all of the keyspace (=
>> brute force) has to be traversed in order to get a valid initial value
>> for any given hash?
>
> Constructing the rainbow table does, however, require traversing the
> entire key space and storing a substantial fraction of the results.
>
> Rainbow tables do quite well storing things like relatively short random
> permutations, such as all alphanumeric combinations up to 10 characters,
> but even that kind of thing can require te. And each additional bit of
> entropy in the input set used to create the rainbow table will cause a
> logarithmic increase in the table's size (or alternately, increase the
> lookup time).

Sorry, this post escaped mid-edit. I was adding a note about rainbow 
table sizes.

There are freely available tables in the ~1TB range that cover input 
sets of around 54 bits of entropy.

Regards,
Sam

0
Sam
2/11/2014 11:23:21 PM
On 2/11/2014 4:13 PM, Mark Cross wrote:
> Using a "salt", and a 128 bit salt just makes sense as nobody will write it 
> and changes nothing in the way the user interacts with the application, 
> makes the password become close to 128 bit strength in result. That is what 
> we should try to keep, even for a shorter password.

+1.  This is the entire purpose and relevance of salt: to "hide"
human-generated passwords within unique solution sets by mixing in a
/trustworthy/ machine-generated random number comprising a larger
keyspace.  This doesn't improve the password itself, but it elegantly
solves the look-up problem so long as the entire hash space cannot be
solved.  Toto, I have a feeling we're not in MD5 anymore...

UAP Salt = full lookup protection + zero user hassle, so Yes.

100-bit+ Access Code = irrelevant protection + extra user hassle, so No.

-- 

 RobAllen
_____________________________________________________
0
RobAllen
2/12/2014 4:22:01 AM
On 2/11/2014 5:42 PM, Sam Schinke wrote:
> So if a PBKDF is worth using, then a salt should be worth using as well.
> IMO, of course.

Exactly.  And each solves a different problem.  Salt solves the lookup
problem *entirely* up to the space of your hash function, while PBKDF is
an inelegant hack by comparison.  PBKDF works well if done right, but
it's a kludge to mitigate a problem we can't solve; that human brains
can only generate 10-bit passcodes to protect 4096-bit encryption
schemes *g*.  I mean, who uses AES-128 anymore?  Did our passwords get
stronger than AES-128? *g*

When using inputs of <cough> substantially <cough> lower bits than your
potential keyspace, a good PBKDF and Salt are simply required
components.  I suspect that the salt should be equal to the output
keyspace.  A lesser salt is okay and is still helpful, but a full-sized
salt assures your input the full keyspace within which to hide from
lookup tables.  It seems to me that one should only use a lesser salt if
they need to conserve storage space or they know exactly what effective
bit-size the secret will be.

-- 

 RobAllen
_____________________________________________________
0
RobAllen
2/12/2014 4:52:11 AM
Reply:

Similar Artilces:

Using "+" or "||"
Using SQLAnywhere 5.5.04, I've gotten into the habit of using "||" in ISQL to indicate a string concatenation. I needed to paste my SQL statement into the PowerBuilder script painter for some embedded SQL, and PB didn't like the "||" very much at all. I changed it to "+" and it seems to be ok. Do these two operators indicate ~exactly~ the same thing? moin, afaik these two's are not the same! if you're using "||" and any term is NULL then in the resultstring the term will be ignored if you use "+" then the resu...

"Using" or "With"
Hi all Please can someone enlighten to me as regards the difference with the "Using" and "With" statement when accessing data - which is better, what are the limitations and/or any pointers. Many thanks. Regards DaveDavid WinchesterPlease mark as answer if this is the solution.  using gives you the ability to use the connection and it closes the connection directlly after you finish using it. and there is no need to try- cach - finaly. there is no limitation on using USING keywordMuhanad YOUNISMCSD.NETMy Blog || My Photos || LinkedIn I have a dataobject the re...

Using "ChangePassword" without needing the "CurrentPassword"
Does anyone know a way to display user passwords ?Web.config is configures to passwordFormat="Hashed"Anyone know how to make this work? I tried : string secret = ChangePassword1.CurrentPassword.ToString();But it wont work ;-), I thought so already.Either this or a way to reset a users password WITHOUT knowing theyre old one. Just simply to override it.Thanks Ok i just replaced it to clear text and it works.If someone still finds a way to decode the hased password or whatever please let me know :P. (probably not possible?)...

Need help to use "object_end_of_create_validators" in "Extension.pm".
Hy, In my file Extension.pm I have 2 validors for 2 custom fields (example: _check_myfield). My goal is to check if those 2 customs fields have a value when we create a bug by email (I use "email_in.pl"). The check works for the fields like "component" but not for my 2 custom fields. I understand I need to use the function object_end_of_create_validators in "Extension.pm" (This function is called by run_create_validators in Object.pm). I read the example but I don't understand how use "object_end_of_create_validators". Can you help me? ...

mapping a drive using "net use" w/no password"
duplicate. -- Regards, Kai Reichert Novell Support Forums Sysop Usually the faulty interface lies between the chair and the keyboard. ...

If I need "Sort" and "Paging" should I use DataList or DataGrid?
I using C# 1.0 , I get Data From SQL 2000 as a DataSet In Header have 5 columns (Date, Items, Action, User , Record) when user click the Date Column of Header , then sort record and in footer I need it shows like →  1234/ Page [TextBox][Button] the 1234 means have total 4 pages and the TextBox allow user to input which Page want to jump toafter click the button then we will jump to the page user input to TextBox if I need these 2 function (sorting and paging) which control I should use?is DataGrid or DataList? or maybe need repeater? thank you If thats the case then I would sugg...

mapping a drive using "net use" w/no password" #2
I want to set up a test scenario where I have a bunch of clients logging into a Netware server using native file access. My clients use a script file which maps shares to the server using the "net use \\server\share /p=no" (for no password). I keep getting "system error 5 - access is denied". What am I doing wrong and what can I do to fix it? Thanks for your help Assuming you're using Local mode, you must assign a Simple password. Note that a blank Simple password is not the same as never assigning a Simple password. bd NSC Voluntee...

RE: Using "do" versus "use" for subroutine
Edward Wijaya wrote: > Hi, > > I would like to know which of this > is better and what is the pro and cons: > > 1. A file "mysub.pl" which stored > a subroutine, and later called by > main file using: do "mysub.pl" > > or > > 2. A file "mysub.pm" and called > in main file using : use "mysub.pm" The second construct is not valid; the argument to "use" must be a bareword. It's not really possible to answer your question without knowing more details. I'm not clear about what&#...

Replacing "use base" with "use parent"
--bcaec554da9c7514d304ca32ffa3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, From the base.pm documentation<http://perldoc.perl.org/base.html#DESCRIPTIO= N>: Unless you are using the fields pragma, consider this module discouraged in favor of the lighter-weight parent . From the parent.pm documentation<http://perldoc.perl.org/parent.html#HISTOR= Y> : This module was forked from base to remove the cruft that had accumulated in it. parent.pm is a 30 lines pure Perl dual module available also in core since 5.10...

Precedence of "where" ("of", "is", "will")?
Nobody on #perl6 today could answer this one. Is: Str | Int where { $_ } the same as: (Str | Int) where { $_ } or: Str | (Int where { $_ }) ? Followup questions, Mr. President: What kind of operators are "where", "of", "is", and "will"? Is there a reason that S03 doesn't list them? What are their precedence(s)? -- Chip Salzenberg - a.k.a. - <chip@pobox.com> Open Source is not an excuse to write fun code then leave the actual work to others. Chip Salzenberg writes: &...

.ALLCOL("%COLUMN%", " ", ", ", ", ")
Do you know anyway for me to exclude a subset of columns returned by this function. We have two columns (rec_user and rec_datetime) which are in all of our tables, but when generating triggers I want automatically generate a script which does not include those two columns but does include all other columns in that table. Bruce I should add that I am using PD 9.0.0.580. Bruce "Bruce Lamb" <lamb.bruce@mayo.edu> wrote in message news:6HgI315nCHA.155@forums.sybase.com... > Do you know anyway for me to exclude a subset of columns returned by this > function. ...

I need to foil using the backbutton to "back into" a "secure" web page
I'm constructing a site which will be "protected" under Forms Authentication. So far, everything works great. The issue I'm trying to overcome now is once a user hits the "Logout" button, which calls FormsAuthentication.Clear() then redirects to my login page, the user can use the back button to go back to the last page of the app they visited, or any others, for that matter. They can't do anything with them except view them or they get bumped to the Login page, but it bugs me that they can even navigate through previously viewed pages! How can I foil this? Thanks! E...

RFC: interactions between "use bytes", "use locale", and "use feature 'unicode_strings'
I am waiting for blead to reopen before I submit a patch for extending feature unicode_strings to matching \s, and \w. In documenting it, it occurred to me that the existing implementation is wrong, along with the existing interaction between use bytes and use locale. To refresh your memory, "use feature 'unicode_strings'" is supposed to mean that even non-utf8 data is to be considered to have Unicode semantics. In practice, this only affects the characters from 128-255. It is new in 5.12, and is implemented there only on functions that change case, such a...

"Save my password" bar
Name: Tomasz Kociemba Product: Firefox Release Candidate Summary: "Save my password" bar - there is no need to use mouse Comments: In FF 2.x question about if password should be saved was erm.. "alert like" with default answer "not now" selected. One additional return key hit was needed to send form. With FF 3 alert pops out as a bar below tabs and with no focus on it. Therefore user is required to use mouse to click one of options - which is waste of time. My sugestion is to add focus on "not now" button when question is given. Ps. I c...

Web resources about - We need a "salt" for used passwords. - grc.sqrl

Resources last updated: 1/11/2016 2:55:43 PM