World: r3wp

yes. The same went for my news-scroller. I just tried to outline 
it in REBOL, thinking someone should do it in some PITL environment. 
Then I saw my brother using it in PC Shop on his LCD TV. I asked 
him - hey, wait till someone makes final version, and he replied 
- it works, no? And then I thought to myself - can I regard 2 pages 
of code being actually an application? :-)

hehe

max, it always scares me when people think that obscurity is a form 
of security...

Gab, are you saying that my idea is only obscurity, or that its the 
proper approach?  just want to confirm what you mean.  the

the idea is for the encryption key to a stored password is created 
dynamically via an algorythm.  
If the software is encapped, then its a pretty safe system IMHO.


But if the software stays open source (and interpreted), at least 
I can use some natives for which the key-gen algorythm is hard to 
reverse engineer.

Although someone with rebol know-how can obviously get the passwd 
by running the algorythm manually, there is no way around this AFAIK.

There is no way to protect a password you are saving. Normally, you 
just want to obfuscate it so that it does not jump to the eyes when 
someone is looking.

if the file containing the password is accessible to other people, 
then the password is accessible to other people.

but that is true of all passwords on a computer even login passwds.

but an encrypted password, without the key isn't usable if you don't 
know the key.

or even the algorythm its encoded with

If you think that keeping the algorithm secret increases the security 
of your encryption then you should not be writing an encryption algorithm. 
it's that simple. :)

The application knows the key, so anyone that can access the application 
knows the key.

the only way to keep a password secret if your files are accessible 
to other people is to not store it into a file.

you mean like in the registry?

I've wondered how useful it is not to store the password itself, 
but encrypting each keypress instead on top of the last keypress.

know that I understand that ultimately there is no method to hide 
any data.

I mean that thing that humans have that's called "memory".

yes ...  and it forgets   ;-)

I have a record right now of 67 passwords I have to remember... I 
mean I can't remember all of them.

right, so you have two options: you make sure noone can access your 
files (like you make sure noone can access your credit card), or 
you make sure you don't forget.

I do remember dozens of passwords, but this is not the point. Now 
you're talking about a different thing, which is a password manager.

A password manager encrypts all your passwords using a single password 
that you have to remember. so you remember just one.

In decent operating systems, that is standard with the OS, so what 
your app does is just communicate with the password manager and store 
passwords there.

yep, but it can be broken, just like any other system, cause it, 
like any system has to store those passwords somewhere.

as long as the master password is not stored anywhere... you are 
safe.

No, it does not have to store the master password anywhere.

You need at least one password you don't store; otherwise, you can 
only try to keep your files out of anyone else hands.

true

And, this is not a problem that *your* app has to solve. It is just 
wasted time for you. Either you make use of a password manager, or 
just use obfuscation.

I'd just use encloak with some random text. If you think it's easy 
enough to get a system specific key, you might do that, but I don't 
know if users will be happy to find out that their passwords don't 
work anymore when they upgrade their PC or move to another computer.

its for a client app... so its not a big issue... its only so the 
software remembers the login for subsequent calls to the server... 
just like all the browsers & OS "do you want   xxxxxx   to remember 
this password"

I'll use real encryption (using command)

Right, and do you think that the browsers are secure, or use a secret 
algorithm for that? :)

its a choice I make.  and I know every single piece of data on my 
computer is vulnerable.

using real encryption does not make any difference... but anyway.

that is what I'm saying... so why waste time with some complicated 
scheme to store the password?

I mean Gabriele, no system in the world is ultimately secure.  The 
point is only to make it unfeasible.

cause its going to be requested from every user the first time they 
have to "re-login"  ;-)

I don't think my point is clear...

I'm saying that it's a waste of time to try to make it "more secure"

or "more unfeasible"

just use encloack and obfuscate it so that it does not jump to the 
eyes.

if someone *wants* to get your password they will get it. so why 
bother?

to make the client happy (the one paying for the application  ;-)

I mean paying me to build it... not the end-user ... ;-)

is the client paying you to use a machine specific id and some secret 
encryption scheme?

he'll want the stored password  toat least require effort and thus 
a real cracker to break the binary. 


this feature will be added later, if ever, it wont for initial public 
release specifically for the reasons you talk about and which I already 
had the same conclusions.

toat = to at

this discussion just re-inforces my POV wrt not including the password 
save feature for now.

what does you make presume that he'll want that? and, what does "real 
cracker" mean?